US 7143438

I'll verify the patent's current status and check for any CAFC 2026 docket activity before summarizing.

US Patent 7,143,438 — Verification Summary

Important scoping note: My searches returned no results for any CAFC 2026 docket or 2026 litigation involving US 7,143,438. I cannot confirm any 2026 appellate activity for this patent, and I am flagging that as an unknown rather than asserting a negative. The litigation data I could retrieve is from 2014 (see below). I also could not confirm the number appears in any CAFC docket — searches for "7143438" Federal Circuit appeal 2026, 7143438 Court of Appeals for the Federal Circuit 2026 docket, and Nokia of America Corp patent 7143438 litigation 2026 all returned empty result sets (the last was cut off by a step limit). Treat the "no CAFC 2026 docket" statement as absence of evidence, not verified absence.

Bibliographic data (per Google Patents, USPTO.report, Unified Patents, FreePatentsOnline)

Discrepancy to flag: Unified Patents' record lists the priority date as 1997-09-11, while Google Patents, the application/priority history, and other sources list 1997-09-12. Google Patents itself notes that priority dates are assumptions, not legal conclusions. I am reporting both literally rather than reconciling them.

Assignment history (per Google Patents): assigned to Lucent Technologies Inc. (1998-03-11); security interest to Credit Suisse AG (2013-03-07, recorded against Alcatel-Lucent USA Inc.); released by secured party to Alcatel-Lucent USA Inc. (2014-10-09).

Abstract (as published)

"The invention provides improved computer network firewalls which include one or more features for increased processing efficiency. 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."

Claims: structure

The patent has 26 claims, of which six are independent: 1, 8, 12, 16, 17, and 22. Note that every independent claim recites the same internal definition — that "a security policy comprises multiple rules" — which is the patent's core claim-construction anchor.

Plain-language overview of each independent claim

Claim 1 — Session-key-driven policy selection (method). Build a "session key" from the packet (header-derived items such as addresses, protocol, ports). Use that key to pick which one of several security policies applies. Then validate the packet against the selected policy. The novelty is that policy selection is driven by the session key rather than a single global rule set.

Claim 8 — Designate multiple independent policies, then determine the right one (method). Stand up several independent security policies on the firewall, figure out which policy is appropriate for a given packet, and validate the packet using at least some of that policy's rules. Broader than claim 1: it does not require a "session key," only that a determination of the appropriate policy be made.

Claim 12 — Apparatus counterpart to claim 8. A processor at the firewall that (i) determines which of the designated independent security policies is appropriate for the packet and (ii) validates the packet using at least a portion of that policy's rules.

Claim 16 — Multi-administrator domain administration (method of providing a firewall). Segment multiple security policies into "domains" (a domain holds at least one policy; a policy holds multiple rules), associate multiple administrators with those domains, and administer rules so that only the administrator for a given domain may modify the rules of a security policy in that domain. This is the administrative/delegation claim — a notable non-technical limitation.

Claim 17 — Computer system, means-plus-function format. Means for obtaining a data item from a session request; means for selecting one of several security policies as a function of that data item; means for applying the selected policy to validate the session's packets. Written in §112(f) "means for" style.

Claim 22 — Method counterpart to claim 17. Obtain a data item from a session request; select one of several security policies based on that item; validate the session's packets using the selected policy. Notably broader than claim 1 in that it does not require a full "session key," only "at least one data item."

Dependent-claim coverage (representative)

• Session-key content: header-derived items (2); source/destination address, next-level protocol, source/destination port (3); the same set expressed as IP (4); TCP or UDP as the next-level protocol (5).
• Interface-based selection: interface at which the request was received (6, 18, 19, 23, 24 — claims 19/24 add reference to the source IP address) and interface to which the request is to be sent (7, 20, 21, 25, 26 — claims 21/26 add reference to the destination IP address).
• Multi-tenant scope: policies corresponding to different groups on a single firewall (9, 13) and to sub-groups within a group (10, 14).
• Administrative exclusivity: only a group's administrator may modify that group's policy rules (11, 15 — parallel to independent claim 16).

Litigation of record

Google Patents lists this patent's family as having litigation, specifically two US District Court, District of Delaware cases cited via Unified Patents:

• Case 1:14-cv-00628
• Case 1:14-cv-00574

Both links are 2014-vintage. No CAFC 2026 docket, and no post-2018 enforcement activity, appeared in my searches. Given the patent's adjusted expiration of 2018-11-23, any 2026 appellate activity would necessarily relate to back damages or a collateral issue rather than ongoing infringement of a live patent — but I could not verify that any such activity exists.

Related sibling patents (same inventors, same 1997-09-12 filing date, Lucent)

These are separate patents that share the specification's subject matter; they are cited as prior art against US 7,143,438 and are not the same patent:

• US 6,098,172 — "…firewall with proxy reflection"
• US 6,154,775 — "…firewall with dynamic rule processing with the ability to dynamically alter the operations of rules"
• US 6,170,012 — "…firewall with cache query processing"

The Google Patents page for US 7,143,438 aggregates summary statements covering all five aspects (multiple domains, stateful filtering, dependency masks, dynamic rules, proxy reflection) because the specifications are family-shared; the claims of this patent are directed to the multiple-security-policy / multi-domain aspect only.

Sources

• https://patents.google.com/patent/US7143438B1/en
• https://FreePatentsOnline.com/7143438.html
• https://uspto.report/patent/grant/7,143,438
• https://portal.unifiedpatents.com/patents/patent/US-7143438-B1
• https://portal.unifiedpatents.com/litigation/Delaware%20District%20Court/case/1%3A14-cv-00628 and .../1%3A14-cv-00574

Explicit uncertainties

1. No CAFC 2026 docket confirmed. My searches produced zero results. I cannot say whether such a docket exists.
2. Priority date conflict (1997-09-11 vs. 1997-09-12) across databases — reported literally, unresolved.
3. Assignee drift: original assignee is Lucent Technologies Inc.; current ownership is listed as Nokia of America Corp, with Alcatel-Lucent USA Inc. appearing in the chain. I did not independently verify the current chain of title at the USPTO Assignment database.
4. I relied on the patent's full text as the authoritative claim source; the claim summaries above are paraphrase, not verbatim quotations of every limitation.

I'll search for litigation involving US patent 7143438, starting with the case references embedded in the patent record and then verifying via litigation databases.

Let me search the specific case numbers and the litigation portal.

Summary of Known Litigation — US Patent 7,143,438

Based on the authoritative patent record for US 7,143,438 B1 and the litigation references it carries, the patent is flagged as having a litigation family, with two confirmed US district court cases in the District of Delaware. Here is what I can state with confidence, and where I must flag uncertainty.

Confirmed litigation references (from the patent record)

Case 1:14-cv-00574 (Alcatel-Lucent USA Inc. v. Fortinet, Inc.) — I confirmed this case exists. The complaint is a multi-patent infringement action filed by Alcatel-Lucent USA (successor-in-interest to the original assignee, Lucent Technologies, Inc.) against Fortinet, Inc. in the U.S. District Court for the District of Delaware. The complaint excerpt I retrieved expressly identifies at least U.S. Patent No. 6,046,979 ("Method and apparatus for controlling the flow of variable-length packets through a multiport switch") and U.S. Patent No. 6,098,172 ("Methods and apparatus for a computer network firewall with proxy reflection") among the patents-in-suit. The '172 patent is a sibling of the '438 patent — same inventors, same 1997-09-12 priority date, same assignee family — but that does not establish that '438 itself was asserted in this case.

⚠️ Important caveat: My search did not surface a portion of the complaint confirming that US 7,143,438 was specifically named as an asserted patent in either case. The Google Patents/Unified Patents linkage establishes that the '438 patent family has litigation involving these two Delaware case numbers, but the excerpt I obtained for -00574 listed the '979 and '172 patents. I cannot confirm from the retrieved text that '438 was among the asserted claims in either action, and I will not assume it was.

Case 1:14-cv-00628 — This case number appears in the '438 patent's litigation record (Delaware District Court), but I was unable to retrieve plaintiff, defendant, filing date, or outcome details before exhausting my search budget. The numbering suggests it was filed in the same 2014 Delaware wave as -00574, which is consistent with Alcatel-Lucent's 2014 assertion campaign, but I cannot confirm this.

Worldwide family litigation

The '438 family is also flagged as having its first worldwide family litigation (Darts-ip family ID 25454664), and the patent record notes the family "has litigation." The '438 patent is part of a three-member family (US 7,143,438 B1; EP0909074B1; JP3492920B2), and the sibling US patents in the same 1997-09-12 filing family — 6,098,172 (proxy reflection), 6,154,775 (dynamic rules), and 6,170,012 (cache query processing) — are all Lucent/Alcatel-Lucent patents.

What I could NOT confirm (stated explicitly rather than guessed)

• Whether US 7,143,438 specifically was one of the patents-in-suit in 1:14-cv-00574 or 1:14-cv-00628 (as opposed to merely being the same family/portfolio).
• The defendant in 1:14-cv-00628.
• The filing dates, docket outcomes, settlements, dismissals, or judgments for either case.
• Any CAFC appeal arising from these cases.

Recommended verification (authoritative sources)

To firmly resolve which patents were actually asserted and the case outcomes, check:

• Unified Patents Portal — https://portal.unifiedpatents.com/litigation/Delaware%20District%20Court/case/1%3A14-cv-00628 and .../1%3A14-cv-00574 (these are the exact links carried in the '438 record).
• PACER (D. Del.) for dockets and outcomes in 1:14-cv-00574-UNA and 1:14-cv-00628.
• Darts-ip family record ID 25454664 for worldwide family litigation.

Bottom line: Two 2014 Delaware district court cases (1:14-cv-00574 involving Alcatel-Lucent USA v. Fortinet, and 1:14-cv-00628) are linked to the US 7,143,438 patent family. I can confirm the Fortinet case's parties and that the suit asserted Lucent/Alcatel-Lucent firewall patents, but I cannot confirm that '438 itself was named as an asserted patent, and I have no confirmed outcomes. If you need a definitive assertion list and disposition, the docket/Unified Patents links above should be pulled directly.

I'll start by checking the canonical structured source and then run targeted searches for any PTAB activity on this patent.

PTAB Activity Report — US Patent 7,143,438 B1

"Methods and apparatus for a computer network firewall with multiple domain support"
Inventors: Coss, Majette, Sharp · Original assignee: Lucent Technologies Inc. · Current assignee of record: Nokia of America Corp. · Filed/priority: 1997‑09‑12 · Granted: 2006‑11‑28 · Adjusted expiration: 2018‑11‑23 · Status: Expired – Lifetime

Verification note: I was able to run only two of the searches I intended before hitting a tool-step limit, and both the structured source (USPTO ODP) and the open-web results came back empty on this point. The absence of proceedings below is therefore stated on the strength of (a) the canonical structured block and (b) the searches I did complete. It is a negative finding, not a confirmed "no one ever filed." I'd re-run a PTAB E2E / Docket Navigator party-name search before relying on it in a brief.

Proceedings overview

Zero AIA trial proceedings on file. The structured "PTAB proceedings on file" block reports that the USPTO Open Data Portal API returns no AIA trial proceedings (IPR, PGR, or CBM) for US 7,143,438, and my independent web searches for an IPR/CBM/PGR petition on this patent surfaced nothing either — no institution decision, no Final Written Decision, no termination, no Federal Circuit appeal. Breakdown: 0 active · 0 claims invalidated · 0 claims sustained · 0 settled · 0 institution denied.

Defensive posture this gives a defendant: all 26 claims are UNTESTED at the PTAB. There are no canceled claims to point to, no FWD to quote, and — importantly — no petitioner-side estoppel under § 315(e)(2) running in your favor, because no one has ever been a petitioner. This is the opposite of a "hardened" patent (an IPR survivor) and the opposite of a "killed" patent (a canceled-claims patent); it is a blank slate. Whatever invalidity case you build, you build from scratch, and you get to pick the art and the forum without inheriting anyone's strategic mistakes.

One flag that is not a PTAB proceeding (per the operating instructions, listed separately so it isn't mistaken for AIA-trial activity): Google Patents' "Family has litigation" block for this patent records two US District Court cases in the District of Delaware — case nos. 1:14‑cv‑00628 and 1:14‑cv‑00574 (source: Unified Patents Litigation Data). These are district-court assertions, generally dated 2014, consistent with Alcatel‑Lucent/Nokia-side assertion activity on this 1997 Lucent firewall family. I could not verify the parties, claims asserted, or outcomes of those cases on the evidence available, and district-court litigation is outside the PTAB scope of this report. Treat them as a lead to pull, not a finding.

Per-proceeding detail

None. No proceeding numbers exist to report, and I will not manufacture any.

Strategic summary

Claim status. With no PTAB trial ever instituted, the claim ledger is simple: claims 1–26 are all UNTESTED. Zero CANCELED. Zero SUSTAINED. Specifically relevant to a defendant: the independent claims — claim 1 (session-key-derived security-policy selection), claim 8 (designating independent security policies and determining which applies), claim 12 (apparatus counterpart to claim 8), claim 16 (segmenting security policies into domains with per-domain administrator authority), claim 17 (computer system with means for selecting a policy from a session data item), and claim 22 (method counterpart to claim 17) — have never been construed or invalidated by the Board. There is no narrowing amendment, no certificate of cancellation, and no adverse judgment that would give you a free shot at any claim.

Estoppel landscape. Because no IPR/PGR/CBM was ever filed, § 315(e)(2) estoppel is a non-factor: no petitioner, no privies, no barred grounds. Every prior-art ground is still available to a defendant — you are not operating in the shadow of a capped, already-litigated art set. Two structural caveats, though:

• This is a pre-AIA patent (effective filing 1997‑09‑12), so PGR is unavailable (PGR applies only to patents with an effective filing date on/after 2013‑03‑16). CBM review was theoretically available for a covered business method patent, but the CBM program sunset for new petitions on 2020‑09‑16, so it is off the table today.
• The patent's adjusted expiration is 2018‑11‑23, and Google Patents shows it as Expired – Lifetime. An expired patent can still be the subject of an IPR in principle, but the practical payoff of invalidating an expired claim (no prospective royalties, damages limited to the pre-expiration window) usually destroys the cost-benefit case. The Board's post-Sony v. Yissum practice permits challenges to expired claims; that is a merits question, not an availability barrier — but budget accordingly.

Pattern signals. There is no petitioner pattern to read: no serial filer, no repeat challenger, no defensive aggregator in the chain on the PTAB side. (Unified Patents maintains a portal page for US‑7143438 and appears in the Google Patents litigation metadata as the source of the Delaware case links — but a data-portal listing and litigation-database attribution are not evidence that Unified filed an IPR, and I found none.) There is likewise no patent-owner appeal pattern, because there has never been a Board decision to appeal. The family citation graph does show a cluster of same-day Lucent siblings — US 6,098,172 (proxy reflection), US 6,154,775 (dynamic rules), and US 6,170,012 (cache query processing) — all filed 1997‑09‑12. If any IPR wave exists on this firewall family, it would most plausibly be against those siblings rather than this patent; checking those three for PTAB proceedings is the single highest-value follow-up and I was not able to complete it here.

Recommended next steps

1. If you are a defendant: there is no FWD to quote and no canceled claim to lean on. Your defense is a first-instance invalidity case, not a "the troll's patent is already dead" argument. Do not represent to a court or opposing counsel that any claim of 7,143,438 has been canceled or held unpatentable — none has.
2. Confirm the negative before you rely on it. Run the patent number and assignee names ("Nokia of America," "Alcatel‑Lucent," "Lucent Technologies") in USPTO PTAB E2E (https://ptab.uspto.gov) and Docket Navigator / CourtListener (https://www.courtlistener.com). Zero-proceeding findings are exactly the findings that age badly.
3. Pull the Delaware cases. Cases 1:14‑cv‑00628 and 1:14‑cv‑00574 (D. Del.) are the only adversary context on record; get the complaints, identify the asserted claims, and check whether any defendant was ever served in a way that started (and has now long since blown) a § 315(b) one-year IPR clock. That clock matters only to defendants who were served — it does not bind you if you weren't, and it does nothing to bar your petition if you're new to the fight.
4. Screen the sibling patents. Check US 6,098,172, US 6,154,775, and US 6,170,012 for PTAB activity. Their outcomes can be informative even though they aren't this patent — same specification lineage, same Lucent firewall family, overlapping claim concepts (session cache, dynamic rules, policy selection).
5. No trial-stage milestones to track. With no pending or instituted proceeding, there is no institution-decision deadline, no oral hearing, and no statutory 1-year FWD deadline running. The absence of any PTAB activity is itself the signal — a 1997 firewall patent that has been in commerce and (apparently) in litigation for years without attracting a single IPR petition suggests either that challengers found district court or licensing more efficient, or that the art most useful against it isn't the kind that makes a clean IPR petition. Either way, do not assume the patent is weak merely because it is un-challenged.

Sources consulted: Google Patents, US7143438B1 — https://patents.google.com/patent/US7143438/en (authoritative full text, claims, citation graph, family-litigation metadata); Unified Patents patent portal — https://portal.unifiedpatents.com/patents/patent/US-7143438-B1 (patent bibliographic data; no PTAB proceedings listed); Unified Patents litigation links embedded in the Google Patents family record — https://portal.unifiedpatents.com/litigation/Delaware%20District%20Court/case/1%3A14-cv-00628 and https://portal.unifiedpatents.com/litigation/Delaware%20District%20Court/case/1%3A14-cv-00574 (D. Del. filings, details unverified).

Caveat on confidence: I have high confidence that no AIA trial proceeding is indexed for this patent as of the most recent USPTO ODP ingest (that is the canonical structured finding). I have moderate confidence that none exists at all, because my independent web verification was incomplete — I could not finish the party-name and classic IPR-number-pattern searches I had queued, and I did not retrieve the PTAB E2E docket directly. Nothing in this report should be quoted as a verified "zero proceedings, confirmed" without that second check.

I'll start by verifying what I can from live sources, since the fetched Google Patents text lacks reel/frame and correspondent data.

Ownership Reconstruction — US 7,143,438 B1

Sources consulted: Google Patents full text + legal events (https://patents.google.com/patent/US7143438/en); Unified Patents patent and litigation portals; USPTO Assignment Center (https://assignmentcenter.uspto.gov/); court dockets surfaced via Unified Patents and third‑party docket mirrors.

⚠️ Data limitation — read first. The live Assignment Center record set for this patent could not be retrieved in this session. The reel/frame numbers and the correspondent-of-record fields are therefore not available to me, and I will not invent them. Everything below that is asserted is grounded in the Google Patents legal-events timeline (which is derived from the same assignment records) and in the litigation documents. Gaps are marked [not retrieved]. Anyone relying on this for prosecution or diligence should pull the reel/frame and correspondent fields directly from Assignment Center.

Inventors

Pattern notes:

• All three inventors assigned to Lucent Technologies Inc. on a single instrument recorded 1998-03-11, i.e. roughly 6 months after the 1997-09-12 filing date. That is a normal, uniform employee-assignment pattern — no sign of inventors scattering to different entities, and no evidence of a post-filing inventor exodus.
• Filing date (1997-09-12) postdates the AT&T → Lucent spin-off (1996), so Bell Labs was operating as the Lucent research arm at filing. The EP (EP0909074B1) and JP (JP3492920B2, "Packet verification method") family members claim the same 1997-09-12 priority, confirming a single corporate filing program rather than a later re-filing or re-acquisition.
• Note that the application was filed 1997-09-12 but did not grant until 2006-11-28 (~9 years). That long pendency is consistent with a large corporate portfolio unit held for defensive/product reasons, not a patent prepared for near-term assertion.

Original assignee

Lucent Technologies Inc. (Murray Hill / Holmdel, New Jersey).

• Line of business: Telecom and data-networking equipment and software; owner of Bell Labs. Spun off from AT&T in 1996.
• Product embodiment: Lucent commercialized a hardware firewall appliance line under the "VPN Firewall Brick" brand (Bell Labs-developed security appliance), and the corresponding product family was carried forward by Alcatel-Lucent after the 2006 merger. The patent's own specification is written as a product/implementation document ("Efficient prototypes of such processes have been implemented as computer system software, using the 'C' programming language for implementation on general-purpose PC hardware"), which supports an internal product-line origin rather than a licensing vehicle. (I am confident in the product family's existence; I have not independently verified in this session which Brick release maps to claim 1.)
• Current status of the original assignee: No longer operating under that name. Lucent Technologies merged with Alcatel in 2006 to form Alcatel-Lucent; the US operating subsidiary became Alcatel-Lucent USA Inc. Nokia acquired Alcatel-Lucent in 2016, and the US subsidiary now operates as Nokia of America Corp. No bankruptcy, no Chapter 7/11, no asset fire-sale. Google Patents lists the current assignee as Nokia of America Corp. (with the caveat that Google states listed assignees "may be inaccurate").

Assignment timeline

Chronological. Reel/frame and correspondent fields are [not retrieved] — see the data limitation above. Conveyance types and dates are taken from the Google Patents legal-events timeline, which mirrors the Assignment Center records.

• 1997-09-12 / recorded [n/a — filing event] — Reel [not retrieved]

  • Conveyance: n/a (application filed)
  • Assignor: n/a
  • Assignee: n/a — application 08/927,382 filed naming Coss, Majette, Sharp
  • Correspondent: [not retrieved]
  • Context: initial filing by Lucent Technologies Inc.; one of several firewall patents filed the same day (siblings include US 6,098,172 "proxy reflection," US 6,154,775 "dynamic rules," US 6,170,012 "cache query").

• 1998-03-11 (recorded) / execution date [not retrieved] — Reel [not retrieved]

  • Conveyance: Assignment of assignors' interest
  • Assignor: Coss, Michael John; Majette, David L.; Sharp, Ronald L. (individuals)
  • Assignee: Lucent Technologies Inc.
  • Correspondent: [not retrieved]
  • Context: ordinary employee invention assignment to the operating employer — not a sale, reorg, or securitization.

• 2006-11-28 — Reel [not retrieved]

  • Conveyance: n/a (grant)
  • Assignor: n/a
  • Assignee: n/a — patent grants as US 7,143,438 B1, assignee of record Lucent Technologies Inc.
  • Correspondent: [not retrieved]
  • Context: issuance. Ownership unchanged.

• 2013-03-07 (recorded) — Reel [not retrieved]

  • Conveyance: Security Interest
  • Assignor: Alcatel-Lucent USA Inc.
  • Assignee: Credit Suisse AG
  • Correspondent: [not retrieved] — this is exactly the field to pull from Assignment Center; Credit Suisse-secured ALU patent grant filings were typically recorded through a single outside firm of record, and recurrence of that correspondent across the ALU portfolio is the kind of pattern worth checking.
  • Context: securitization / collateral pledge, not an ownership transfer. The assignor name change Lucent Technologies Inc. → Alcatel-Lucent USA Inc. reflects the 2006 Alcatel-Lucent merger (recorded as a merger/change-of-name instrument; the specific record was [not retrieved]).

• 2014-10-09 (recorded) — Reel [not retrieved]

  • Conveyance: Release by Secured Party
  • Assignor: Credit Suisse AG
  • Assignee: Alcatel-Lucent USA Inc.
  • Correspondent: [not retrieved]
  • Context: release of the 2013-03-07 security interest, returning unencumbered title to Alcatel-Lucent USA Inc. Note the release postdates the May 2014 Delaware complaint (below), meaning the plaintiff was suing while the portfolio was still under a recorded security interest.

• c. 2016 (effective) / record [not retrieved] — Reel [not retrieved]

  • Conveyance: Merger or change of name (Alcatel-Lucent USA Inc. → Nokia of America Corp.)
  • Assignor: Alcatel-Lucent USA Inc.
  • Assignee: Nokia of America Corp.
  • Correspondent: [not retrieved]
  • Context: internal corporate reorg following Nokia's acquisition of Alcatel-Lucent. I did not verify whether this was recorded as a Merger, a Change of Name, or not separately recorded at all — Google's current-assignee field is consistent with it, but the instrument itself is [not retrieved].

• 2018-11-23 — legal status

  • Context: adjusted expiration; patent now Expired – Lifetime.

If Assignment Center in fact returns only the three records I can see (1998 assignment, 2013 security interest, 2014 release), that itself is the headline finding: there is no post-issuance assignment of title away from the Lucent → Alcatel-Lucent → Nokia corporate line. Title never left the operating-company family.

Timeline diagram

timeline
    title Ownership of US 7143438
    1997 : Application filed by Lucent Technologies
    1998 : Inventors assign to Lucent Technologies
    2006 : Patent granted as US 7143438
    2013 : Security interest recorded to Credit Suisse AG
    2014 : Credit Suisse releases security interest
         : Alcatel Lucent sues Fortinet and Sophos
    2016 : Alcatel-Lucent acquired by Nokia
    2018 : Patent expires

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT.
The only entities ever holding title are Lucent Technologies Inc., Alcatel-Lucent USA Inc., and Nokia of America Corp. — all large operating telecom/networking manufacturers with named products (Lucent/Alcatel-Lucent VPN Firewall Brick line) and public financials. No "IP / Holdings / Licensing / Ventures" suffix appears anywhere in the chain. Credit Suisse AG appears only as a secured lender, which is not ownership.

2. Known asserter in the chain — NOT PRESENT.
No assignee matches any of the listed NPE directories (Acacia, Marathon, IV, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, etc.). Unified Patents classifies the parent company as Nokia, not an NPE, and its patent page lists the assignee chain as Lucent → Nokia of America Corp. (https://portal.unifiedpatents.com/patents/patent/US-[7143438](/patent/7143438)-B1).

3. Repeat correspondent across the chain — UNCLEAR / NOT ASSESSABLE.
The correspondent-of-record field could not be retrieved for any link. I will not name an attorney on the basis of the entity names alone. Action item: pull the correspondent for the 2013-03-07 Credit Suisse security-interest record and the 2014-10-09 release — the same recorder firm appearing on both is expected (they are the mirror-image pair of one financing), and the more interesting check would be whether that firm also appears as correspondent on the 1998 assignment, which would be unusual.

4. Cascading transfers — NOT PRESENT.
The recorded instrument spacing is ~15 years (1998 → 2013), not a chain of LLC-to-LLC hops inside 24 months. Nothing resembling a conduit structure.

5. Pre-litigation transfer — NOT PRESENT.
There is no assignment of title within 6 months before the first suit. The Alcatel-Lucent filings were made by the existing owner of record. Two 2014 Delaware actions are flagged on the face of the patent record:

• 1:14-cv-00574-UNA — Alcatel-Lucent USA Inc. v. Fortinet, Inc. (D. Del., 2014)
• 1:14-cv-00628-UNA — Alcatel-Lucent SAS v. Cyberoam Inc. et al. (Sophos Inc.), complaint filed on/about 2014-05-20, expressly listing US 7,143,438 B1 among the patents-in-suit alongside US 6,286,050; 6,347,087; 6,888,797; 6,944,183. Plaintiff's Rule 7.1 disclosure identified corporate parent Alcatel Lucent SA.

The proximity of the 2014-10-09 Credit Suisse release to the May 2014 suits is a financing/encumbrance artifact, not a title transfer enabling assertion.

6. Bankruptcy fire-sale — NOT PRESENT.
Neither Lucent, Alcatel-Lucent, nor Nokia filed Chapter 7/11; Alcatel-Lucent's end state was a merger/acquisition, not a liquidating estate. No Kodak/Nortel/Polaroid-style patent auction appears in this chain.

7. Privateering — NOT PRESENT.
The assertion was made by the product company itself (Alcatel-Lucent USA Inc., parent disclosed as Alcatel Lucent SA) against direct competitors in the network-security appliance market — Fortinet, Sophos, and Cyberoam all sell next-gen firewall appliances. There is no record of a transfer to a third-party NPE asserting on Alcatel-Lucent's behalf.

8. Defensive aggregator — NOT PRESENT.
The chain does not terminate at RPX, AST, LOT, Unified Patents, or OIN. It terminates inside Nokia. The patent is instead neutralized by expiration (2018-11-23).

Verdict

Operating-company assertion.

The complete recorded chain runs Lucent Technologies Inc. → (1998-03-11 inventors' assignment) → Alcatel-Lucent USA Inc. → Nokia of America Corp., with the only non-title events being a 2013-03-07 Credit Suisse AG security interest and its 2014-10-09 release by secured party — a collateral pledge, not a transfer of ownership. Title never entered an NPE, no shell/holdings entity appears, and the patent was asserted by the operating owner itself: Alcatel-Lucent USA Inc. filed D. Del. 1:14-cv-00574 against Fortinet and Alcatel-Lucent SAS filed 1:14-cv-00628 against Cyberoam and Sophos, the latter complaint naming US 7,143,438 B1 among the patents-in-suit. The patent expired 2018-11-23, so it is no longer assertable by anyone.

Two caveats to carry forward: (i) I could not retrieve reel/frame or correspondent data, so the "repeat correspondent" test is unanswered rather than negative; (ii) Google Patents' current-assignee field is self-described as potentially inaccurate, and the Alcatel-Lucent USA Inc. → Nokia of America Corp. step is a corporate name/merger event whose recorded instrument I did not verify.

Verify at:

• USPTO Assignment Center — https://assignmentcenter.uspto.gov/ (search by patent number 7143438; also https://assignment.uspto.gov/patent/index.html)
• Google Patents legal events — https://patents.google.com/patent/US7143438/en
• Unified Patents patent page (assignee chain + litigation flags) — https://portal.unifiedpatents.com/patents/patent/US-7143438-B1
• Unified Patents litigation entry for 1:14-cv-00628 — https://portal.unifiedpatents.com/litigation/Delaware%20District%20Court/case/1%3A14-cv-00628

I'll start by retrieving the authoritative record for this patent and its citation set, then research the individual references.

Now let me research the cited prior-art references individually.

Prior-Art Analysis — US 7,143,438 B1

0. Scope, sources, and honesty caveats (read first)

I did not retrieve a native USPTO PatentCenter/PAIR page. I could not query the USPTO database directly; my tooling returned Google Patents (which mirrors USPTO/EPO bibliographic data), the Unified Patents litigation portal, uspto.report (an independent third party, not affiliated with the USPTO), and FreePatentsOnline. The citation lists, dates and titles below are taken from the authoritative full text supplied in the record for this patent (Google Patents US7143438B1 page, fetched 2026-09-12T01:01:53Z), cross-checked against the third-party mirrors. Where I have not read a reference's full specification, I say so rather than inventing a disclosure.

Date note: the task header says "Current Date: April 26, 2026" while the system/record timestamp is 2026-09-12. I have not "corrected" either; the analysis is date-insensitive except as noted.

Critical framing on § 102. US 7,143,438 was filed 1997-09-12 (Appl. No. 08/927,382), i.e. pre-AIA. Only pre-AIA § 102(a), (b), (e) and (g) are available; there is no § 102(a)(1)/(a)(2). Second, and more important: all 16 references in the "Patent Citations" list were before the examiner, and the claims issued over every one of them. So no reference was found anticipatory, and the "anticipation" mapping below is a hypothesis about which claims each reference could reach if construed broadly, not a record finding. Anticipation requires a single reference disclosing every element of the claim; several entries below are better characterized as § 103 (obviousness) or background art.

1. Identification of the patent (no substitution)

Because this patent published 2006-11-28 and is now expired, its practical prior-art significance today is as a printed publication against later filings (e.g. the Centripetal Networks family), not as a live patent to invalidate.

2. What the claims actually require (so the § 102 mapping has an anchor)

• Claim 1 — derive a session key for the packet; select at least one of a plurality of security policies as a function of the session key, where a security policy comprises multiple rules; use the selected policy to validate the packet.
• Claims 2–5 — the session-key content (header items; source/destination address; next-level protocol; source/destination port; TCP or UDP).
• Claims 6–7 — selection based on network interface in (received at) or out (sent to).
• Claim 8 — designate a plurality of independent security policies; determine which policy is appropriate for the packet; validate using at least a portion of that policy's rules. (Claim 12 = apparatus analogue.)
• Claims 9–11 / 13–15 — policies correspond to different groups / sub-groups of a single firewall; only an administrator for a group may modify that group's rules.
• Claim 16 — segment a plurality of security policies into a plurality of domains, with a plurality of administrators, and administer so that only that domain's administrator may modify that domain's rules.
• Claims 17–21 / 22–26 — means-plus-function and method analogues: obtain a data item from a session request; select a policy as a function of that data item; validate session packets; interface determination via source IP address (in-bound) or destination IP address (out-bound).

3. Reference-by-reference analysis

Below, entries marked (※) were cited by the examiner (asterisk in the record); the rest are third-party/applicant citations.

3.1 Check Point family — three entries, one disclosure

(a) US 5,606,668 A (※) — "System for securing inbound and outbound data packet flow in a computer network," Checkpoint Software Technologies Ltd. Priority 1993-12-15; granted 1997-02-25.
(b) WO 97/000471 A2 — "A system for securing the flow of and selectively modifying packets in a computer network," Check Point Software Technologies Ltd. Priority 1993-12-15; published 1997-01-03.
(c) US 5,835,726 A (※) — same title as (b), Check Point. Granted 1998-11-10.

• Description. Gateway/firewall that inspects inbound and outbound packets and passes or drops them against a rule base (the Check Point FireWall-1 lineage). Also the target of the non-patent citations in this record (OPSEC spec; EliaShim anti-virus plug-in).
• § 102 exposure. Claim 1's preamble-plus-"validating said packet using rules" is arguably met by a rule-base packet filter, and claims 2–5's header tuple is the classic filter key. The dispositive gap is the "plurality of security policies" + "selecting … as a function of the session key" limitation: these references describe a single rule base, not policy selection.
• Potential § 102 target claims: 1, 2–5 (weak, generic reading only). None of 8–16 or 17–26.
• Confidence: low. More likely a § 103/background citation.

3.2 US 5,623,601 A (※) — Milkway Networks Corporation

• Citation. "Apparatus and method for providing a secure gateway for communication and data exchanges between networks." Filed 1994-11-18; granted 1997-04-22. (Assignee spelled "Milkway" in this record; the EP counterpart EP0713311A1 is spelled "Milkyway" — I have not auto-corrected either.)
• Description. Secure gateway between networks, with proxy/authenticated-pipeline-style filtering of exchanges.
• § 102 exposure. Reaches only the generic "validate a packet at a gateway" concept.
• Potential § 102 target claims: 1 (weak); none of the multi-policy claims.
• Confidence: low. § 103/background only.

3.3 US 5,550,984 A (※) — Matsushita Electric Corporation of America

• Citation. "Security system for preventing unauthorized communications between networks by translating communications received in IP protocol to non-IP protocol to remove address and routing services information." Filed 1994-12-07; granted 1996-08-27 (⇒ fully available under pre-AIA § 102(b)).
• Description. Security achieved by protocol translation (IP → non-IP) so that internal addressing/routing is stripped, rather than by policy selection.
• § 102 exposure. Effectively none for claims 1–26. It discloses a different mechanism (translation) than any claim's policy-selection/core validation step.
• Potential § 102 target claims: none identified.
• Confidence: high that this is not an anticipation reference.

3.4 EP 0 743 777 A2 — Sun Microsystems, Inc.

• Citation. "System for packet filtering of data packets at a computer network interface." Priority date shown 1995-05-18; published 1996-11-20.
• Description. Packet filtering performed at the network interface level.
• § 102 exposure. Interesting for the interface-oriented claims (6, 7, 18–21, 23–26), because it expressly locates filtering at a network interface. It does not disclose selecting among several independent policies.
• Potential § 102 target claims: 6, 7 (weakly); possibly 18–21 / 23–26 as to the "interface" sub-features.
• Confidence: low-medium; § 103 in combination is the more realistic theory.

3.5 WO 97/02734 A2 — Cabletron Systems, Inc.

• Citation. "Internet protocol (IP) work group routing." Priority date shown 1995-07-12; published 1997-01-30.
• Description. IP routing organized around work groups. I have not read the specification; a work-group routing disclosure is the most plausible source in this set for the "different groups / sub-groups associated with a single firewall" and interface/group-determination concepts.
• § 102 exposure. Potentially claims 6–7, 9–11, 13–15 and 18–21 / 23–26, if it discloses per-group forwarding/filtering decisions driven by interface and address. Not verifiable without the text.
• Potential § 102 target claims: 6, 7, 9, 13 (provisional/unverified).
• Confidence: low — flagged as the reference I would read next.

3.6 US 5,826,014 A (※) and US 5,898,830 A (※) — Network Engineering Software

• Citation. (i) "Firewall system for protecting network elements connected to a public network," filed 1996-02-06, granted 1998-10-20. (ii) "Firewall providing enhanced network security and user transparency," filed 1996-10-17, granted 1999-04-27. Both are pre-1997-09-12 filings ⇒ available under pre-AIA § 102(e).
• Description. Firewall systems with per-element/per-user access control and transparency features. US 5,898,830 in particular is directed to user transparency — i.e. differentiated treatment of sessions on a per-user basis — which is the conceptual neighbour of "multiple users, multiple policies." I have not read either specification, so the mapping is provisional.
• § 102 exposure. Plausibly the "selection of a policy per user/session" concept, i.e. claims 1, 8, 12, 17, 22, if either discloses discrete independent rule sets selected per user/session.
• Potential § 102 target claims: 1, 8, 12, 17, 22 (provisional/unverified).
• Confidence: low-medium; cannot be asserted as anticipation on titles alone.

3.7 Storage Technology Corporation family — the strongest § 102 candidate

(a) US 5,842,040 A (※) — "Policy caching method and apparatus for use in a communication device based on contents of one data unit in a subset of related data units." Inventors Hughes & Olson. Filed 1996-06-18 (Appl. No. 08/666,638); granted 1998-11-24 ⇒ pre-AIA § 102(e) prior art as of 1996-06-18.
(b) WO 97/49038 A1 — "Policy caching method and apparatus for use in a communication device." Priority 1996-06-18; published 1997-12-24 (i.e. after the 1997-09-12 filing, so it is not § 102(a)/(b) art; the operative hook is the 1996-06-18 US filing).

• Description (from the full text I retrieved). A communication device — expressly including "a firewall" (claims 9, 16, 35) — determines "an instance of protocol data unit (PDU) network policy from a plurality of policies to be applied to related-received PDUs based on contents of one of the related-received PDUs," caches the policy identification information, and applies that instance to later related PDUs. The specification distinguishes filtering (forward/not forward) and auditing policies, and defines the unit of relatedness as: "every combination of protocols, addresses, and ports is a key. This tuple (called a session) represents a single TCP or UDP session." Independent claims 1, 11, 18 are directed to this.
• § 102 exposure — element mapping to US 7,143,438 claim 1:

• Potential § 102 target claims: 1, 2–5, 8, 12, 17, 22 — the best fit in the entire citation set. It does not reach the interface-based selection of claims 6–7 / 18–21 / 23–26, nor the administrator-per-domain limitations of claims 11, 15, 16.
• Confidence: medium-high for the "plurality of policies" limitation; it is the single reference I would lead with. Note that the Federal Circuit in Storage Technology Corp. v. Cisco Systems (Fed. Cir. 2003) construed "policy caching method/policy cache" preambles as non-limiting and read claim 1 as requiring only caching of policy identification information — relevant if anyone tries to rely on '040's cache claims rather than its plurality-of-policies disclosure.

3.8 AT&T Corp. — EP 0 856 974 A2

• Citation. "Session cache and rule caching method for a dynamic filter." Priority 1997-01-15 (US Appl. 08/783,180); EP filed 1998-01-07; published 1998-08-05. US counterpart: US 6,173,364 B1 (Zenchelsky et al.), filed 1997-01-15, granted 2001-01-09 ⇒ that US filing is the operative § 102(e) reference (filed 1997-01-15, i.e. before 1997-09-12).
• Description (from the full text I retrieved). A session cache whose entries are keyed by a session key = 5-tuple (source address, source port, destination address, destination port, protocol identifier), with multiple rule bases: a global pre-rule base, per-peer local rule bases (peer-in and peer-out), and a global post-rule base; local rule bases are loaded when a peer authenticates and ejected when it de-authenticates, so the applicable rule base is determined by the identity (address) of the source/destination peer.
• § 102 exposure. This is a strong reference for:
  • Claims 1, 2–5 — session key derived from header fields; rule set applied keyed on the session;
  • Claim 8 — arguably "a plurality of independent security policies" (the global vs. per-peer rule bases), with the applicable one determined per packet;
  • Claims 17, 22 — selecting the governing rule set as a function of a data item from the session request (peer address).
• Potential § 102 target claims: 1, 2–5, 8, 17, 22. Timing is the key practical point: EP0856974A2's own publication (1998-08-05) post-dates the '438 filing, so the § 102 case must be built on the US 08/783,180 filing (1997-01-15) — which the '438 record cites only indirectly, through the EP number.
• Confidence: medium-high on disclosure; the § 102 posture depends on using the US counterpart's date.

3.9 Sun Microsystems — US 5,848,233 A (※)

• Citation. "Method and apparatus for dynamic packet filter assignment," inventors Radia et al., filed 1996-12-09; granted 1998-12-08 ⇒ pre-AIA § 102(e) (filed 1996-12-09 < 1997-09-12).
• Description (from the full text I retrieved). A Services Management System maintains "a series of filtering profiles, each of which includes one or more of filtering rules"; on client connect a default login filtering profile is downloaded to an Access Network Control Server and installed as the packet filter; on successful user login the SMS "selects or generates a user filtering profile sequence," which replaces the login profile. Filtering rules include protocol type, destination address, destination mask, and destination port ranges.
• § 102 exposure — element mapping to claim 8: "designating a plurality of independent security policies" ← the series of filtering profiles (login profile, per-user profiles); "determining which security policy is appropriate for the packet"/user ← SMS selecting the user profile on login; "validating the packet using at least a portion of the multiple rules" ← the ANCS packet filter installing and applying that profile's rules. Also squarely supports claims 3–4 (rule fields = destination address / port / protocol) and the "only an administrator for a given group" concept of claims 11/13/15 to the extent the SMS is the sole rule-setter.
• Potential § 102 target claims: 8, 12, 17, 22, and (weaker) 1, 3, 4, 9, 11, 13, 15.
• Confidence: medium — a plausible second-lead reference for the "plurality of policies" limitation, though selection there is event/user-driven rather than session-key-driven.

3.10 The three Lucent co-pending siblings — not prior art

• US 6,098,172 A — "Methods and apparatus for a computer network firewall with proxy reflection," filed 1997-09-12, granted 2000-08-01.
• US 6,154,775 A — "Methods and apparatus for a computer network firewall with dynamic rule processing with the ability to dynamically alter the operations of rules," filed 1997-09-12, granted 2000-11-28.
• US 6,170,012 B1 — "Methods and apparatus for a computer network firewall with cache query processing," filed 1997-09-12, granted 2001-01-02.

These appear in the citation list because they are same-day, same-family, common-inventor Lucent applications (the record lists the same assignors for the '438: Coss, Majette, Sharp). For § 102 purposes they are ineligible: same-day filings are not "by another … before the invention thereof by the applicant" (pre-AIA § 102(a)/(e)) and had not issued or published before the '438 filing. Their real relevance would be obviousness-type double patenting / terminal disclaimer, not anticipation.
Potential § 102 target claims: none. (Do not use these as § 102 art.)

3.11 Not prior art for § 102 purposes

• The "Cited By" lists (60 examiner-cited postings, ~169 third-party) are later documents citing the '438 — they post-date 1997-09-12 and cannot anticipate it.
• Non-patent citations (3):
  1. Check Point FireWall-1™, OPSEC Open Specification, Version 1.01, Check Point Software Technologies Ltd., pp. 1–72, Nov. 1998 — anomalous: a November 1998 publication cannot be prior art to a 1997-09-12 filing. Treat it as an IDS-style submission, not § 102 art.
  2. E. Amoroso et al., PCWEEK Intranet and Internet Firewall Strategies, Ziff-Davis Press, 1996 — § 102(b)/§ 103 background; generic firewall practice, no multi-policy selection shown.
  3. Press release, "EliaShim Ltd. Announces CVP-Compliant Anti-Virus Plug-In for Check Point FireWall-1," pp. 1–2, Feb. 17, 1997 — background on proxy/plug-in services; not anticipation.

4. Ranking: most relevant prior art for US 7,143,438

5. Bottom line

1. No reference in the '438 record was held anticipatory — the claims issued over all 16. Treat every "§ 102" mapping above as a hypothetical, not a finding.
2. The two references that actually put the claim-1/claim-8 "plurality of security policies" limitation at risk are US 5,842,040 (Storage Technology) and the AT&T session-cache disclosure (US 6,173,364 / EP 0 856 974 A2), with US 5,848,233 (Sun) a credible third. All three are § 102(e)-anchored on pre-1997-09-12 US filing dates — a point worth noting, because for the AT&T and StorageTech families the publication dates (1998-08-05 and 1997-12-24) fall after the '438 filing and cannot carry a § 102(a)/(b) case on their own.
3. The domain/interface-specific claims (6–7, 18–21, 23–26) and the administrator-per-domain claim (16) are the hardest to anticipate from this set, which is consistent with the '438 being directed at multiple-domain support as its point of novelty.
4. Do not cite the three Lucent same-day applications (US 6,098,172; US 6,154,775; US 6,170,012) as § 102 prior art. They are co-pending siblings and, at most, raise double-patenting considerations.
5. I could not verify the internal disclosures of US 5,826,014, US 5,898,830 and WO 97/02734 from full text; the mappings for those three are provisional and should be confirmed against the specifications before being relied upon.

I'll ground this analysis in the prior-art references listed on the US 7,143,438 page. Let me verify what several of the key references disclose before combining them.

Obviousness Analysis — US 7,143,438 B1

Patent: Methods and apparatus for a computer network firewall with multiple domain support — https://patents.google.com/patent/[US7143438B1](/patent/US7143438B1)/en
Application: US 08/927,382 · Filed / Priority: 1997‑09‑12 · Granted: 2006‑11‑28
Inventors: Coss, Majette, Sharp · Original assignee: Lucent Technologies Inc. · Status: Expired – Lifetime (adjusted expiration 2018‑11‑23)
Statutory framework: Pre‑AIA 35 U.S.C. § 103(a) (Graham v. John Deere; KSR Int'l v. Teleflex). Priority date 1997‑09‑12 governs all prior‑art date determinations.

Note on one listed reference: the Non‑Patent Citation "Check Point FireWall‑1™, OPSEC Open Specification, Version 1.01 … Nov. 1998" post‑dates the 1997‑09‑12 filing date by more than a year and therefore is not § 102/§ 103 prior art to this patent. It cannot support an obviousness rejection. Only the Amoroso et al. PCWEEK Intranet and Internet Firewall Strategies (Ziff‑Davis, 1996) and the EliaShim press release (1997‑02‑17) among the NPL citations are date‑eligible.

1. The recurring claim limitations

Across the six independent claims (1, 8, 12, 16, 17, 22), the asserted invention reduces to a small set of limitations. Everything else is plumbing.

Limitations (A)–(D) are the whole inventive weight. Limitation (E) (claim 16, and its dependents 11/15) carries the only meaningful administrative flavor and is addressed separately in §5 below because the date‑eligible art supports it far more weakly.

2. The date‑eligible prior‑art arsenal

3. Primary combination — would render claims 1, 8, 12, 17, 22 obvious

Combination 1: US 5,848,233 (Sun) in view of EP 0 856 974 (AT&T) and US 5,835,726 (Check Point).

Claim‑by‑claim mapping:

• Limitation (B) — "a plurality of security policies, each comprising multiple rules." US 5,848,233 discloses exactly this structure: a services management system "maintains a series of filtering profiles, each of which includes one or more of filtering rules," with distinct login profiles versus user profiles. Check Point '726 independently describes a rule base whose individual rules each specify source, destination, service, and accept/reject — the "security policy" element in the patent's own vocabulary. One of ordinary skill would recognize Sun's "filtering profile containing filtering rules" and Check Point's "security policy comprising a rule base" as the same abstraction.

• Limitation (C) — "selecting … as a function of the session key / data item." US 5,848,233 selects the filtering profile based on a detected event associated with the client system and on "who the user is." EP 0 856 974 supplies the linking mechanism: it keys its session cache and rule lookup on the packet's 5‑tuple (source address, destination address, source port, destination port, protocol) and searches multiple rule bases for a matching rule. Substituting AT&T's 5‑tuple key for Sun's event/user key to choose which of Sun's profiles applies is the substitution of one known index for another to obtain the same predictable result — searching/selecting by connection identity rather than by event. KSR at 1739‑40 (predictable variation; "familiar elements according to known methods"). This also satisfies claim 3/4 (the recited session‑key fields) almost verbatim, and claim 5 (TCP vs. UDP) through AT&T's protocol identifier.

• Limitation (A) — "deriving a session key." EP 0 856 974: the cache entry is "derived from at least one rule having a rule key … the identification data of the received packet" — i.e., the 5‑tuple. Check Point '726's SMLI similarly maintains per‑connection state.

• Limitation (D) — "using the selected policy to validate." All three references validate (PASS/DROP/ACCEPT/REJECT) using the selected rule set.

Why one of ordinary skill would combine. The problem the '438 patent itself identifies — a single firewall plane serving more than one protection domain — is the problem Sun's profile system and AT&T's multi‑rule‑base filter were each already addressing from the other direction (Sun: per‑subscriber profiles; AT&T: per‑peer local rule bases with global pre/post layers). Motivating factors under KSR: (i) both references are in the same field (network firewalls) and address the same problem (per‑user/per‑peer differentiated filtering on a shared filter); (ii) the predictable, finite set of known solutions to "which rule set applies to this packet?" is exactly index by connection identity, by interface, or by user/event — the patent's insight is one of these; and (iii) the economic/design incentive to consolidate multiple customers/domains onto a single firewall processor (the patent's own FIGS. 1 and 2, where firewall processor 111 is "configured to serve the two sites 101 and 102") is a well‑documented ISP/corporate objective, expressly discussed in AT&T's EP 0 856 974 background in the ISP context.

Result for claim 1 / 8 / 12 / 17 / 22: obvious over Sun '233 + AT&T case (EP 0 856 974 / US 6,173,364), further in view of Check Point '726.

4. Secondary combination — interface‑based selection (claims 6, 7, 18‑21, 23‑26)

Combination 2: Combination 1 further in view of EP 0 743 777 A2 (Sun).

Claims 6/7 (and 18‑21, 23‑26) require that the selecting step include "determining the interface at which the request was received" / "to which the request is to be sent," and (claims 19/21/24/26) referring to the source or destination IP address.

EP 0 743 777 A2 is directly on point: it describes a screening system with multiple network interfaces that filters packets "based upon their contents, state information and other criteria, including their source and destination." Check Point '668 likewise discloses packet filters installed on the specific connection between each network object (its FIG. 2), i.e., interface‑specific filter placement, and its "Install On" column in the rule base editor (see the '726 rule‑base editor figure) is a direct teaching of specifying the interface where a rule is enforced. Combining AT&T's 5‑tuple rule‑lookup key with Sun/Check Point interface‑based filter placement yields the dependent claims' subject matter as an obvious aggregation of two known selection keys (interface + connection identity), producing no unexpected synergy.

Result: claims 6, 7, 18‑21, 23‑26 obvious.

5. The weakest claims — 9‑11, 13‑15, and especially 16

• Claims 9/13 ("different groups associated with a single firewall") — reasonably supported. Check Point '668/'726 expressly permit grouping hosts ("the finance department, the research and development department, the directors of the company") and enforcing rules per group. Grouping clients into administrative groups on one firewall is a routine data‑organization step.

• Claims 10/14 ("sub‑groups within a given group") — the date‑eligible art is thinner. Sun '233 affords per‑client profiles within the ISP whole; Check Point affords group objects. A nested group hierarchy is a conventional hierarchical organization of the same data (cf. B‑tree/segment‑tree classification and the "subnetwork" example Sun gives in US 5,848,233: "instead of saying that access is allowed to a host with address xyz, one says that access is allowed to hosts with address xy*"). Arguable but not airtight.

• Claim 16 (and 11/15) — "a plurality of administrators … only an administrator for a given domain is permitted to modify rules of a security policy for that domain." I could not locate this multi‑administrator, per‑domain write‑access segregation in any date‑eligible reference on the page. The obvious candidates are all post‑dating and therefore unavailable: e.g., EP 1062785 A2 (Secure Computing, 1998‑03‑18 priority) and US 2006/0150243 A1 (BAe Systems) appear only in the "Families Citing this family" list, and the Check Point FireWall‑1 OPSEC spec is Nov. 1998. The best available support is a KSR‑style "predictable administrative arrangement" argument (once independent, separately administered domains exist on one box, limiting each administrator's write authority to his own domain is the natural implementation of that independence), reinforced by Check Point's disclosure that the actor generating a rule base is a "system administrator" and that rule bases are edited as discrete, per‑installation files ("RULE BASE SAVED TO '/FW/USERS/MARLUS/CORPORATE.W'"). That is a design‑choice / predictable‑use argument, not a clean reference‑mapping argument, and an examiner/defendant relying on the listed art alone would find claim 16 the hardest of the independents to invalidate.

6. Safeguards, caveats, and what I cannot confirm

1. Pre‑AIA § 103(c) — the three Lucent sibling applications. US 6,098,172, US 6,154,775, and US 6,170,012 are cited on the face of the patent, share the same 1997‑09‑12 filing/priority date, and share the same assignee (Lucent). They are usable only under § 102(e)/(f)/(g), and pre‑AIA § 103(c) disqualifies commonly owned § 102(e) art for obviousness. They should therefore not be relied on in a § 103 combination absent evidence of different, non‑common ownership. (Their cited titles — proxy reflection, dynamic rules, cache query — also simply do not supply the "multiple domain" concept.)

2. What limitation (B)/(C) actually reads on. I have relied on the titles and abstracts of the cited references plus the limited full text retrieved above. I did not retrieve claim‑level text of EP 0 743 777 A2, US 5,848,233, or US 5,842,040 in full; my characterization of those references rests on the abstracts/spec passages quoted in the search results and should be confirmed against the complete specifications before being used in a formal rejection. I state the mappings in §3 as reasonably supported, not as verified element‑by‑element anticipations.

3. This analysis is not a validity opinion. Several limitations — most importantly the per‑domain administrator of claim 16, and nested sub‑groups of claims 10/14 — are not squarely met by the art listed on this page. A full § 103 analysis would require searching beyond the face‑of‑patent citations (e.g., contemporaneous multi‑tenant firewall administration literature from 1996–1997, which I have not searched here).

4. Secondary considerations. No evidence of unexpected results, long‑felt need, or industry praise is presented on the page. The commercial success of the Lucent firewall line (and the later Delaware litigation, case nos. 1:14‑cv‑00628 and 1:14‑cv‑00574) is a nexus question that cannot be resolved without an evidentiary record.

7. Bottom line

The single most dangerous combination to this patent is Sun's US 5,848,233 (plural filtering profiles each containing rules, selected per user/event) combined with AT&T's EP 0 856 974 / US 6,173,364 (5‑tuple session key, multiple rule bases, cache lookup), optionally with Check Point's US 5,835,726 for the session‑key/stateful‑validation element. The motivation is the same one the patent recites — consolidating multiple protection domains onto one firewall — which both references independently recognize in the ISP/enterprise context.