US 5968176

I'll search for authoritative information on this patent, including any 2026 CAFC docket activity.

Let me dig deeper for the patent's claims text and any litigation/CAFC activity.

Let me try to retrieve the actual claim text and check for any 2026 court activity.

Patent Analysis: US 5,968,176

Search scope and caveats

I searched for the literal identifier 5968176 / US5968176A plus 2026 CAFC docket references. Two caveats up front:

1. No 2026 CAFC activity found. Nothing in my search results ties US 5,968,176 to a Federal Circuit docket in 2026 (or any year). The 2026 CAFC material that surfaced (Enanta v. Pfizer, Google v. Cellular South, Contour IP v. GoPro, Apple/Masimo) is unrelated to this patent. I cannot affirmatively state a CAFC 2026 docket exists for 5968176 — and there are strong reasons to expect none (see "Legal status" below). Treat "no docket found" as an absence of evidence, not proof of absence, since I could not query PACER/CAFC docket systems directly.
2. The authoritative full text supplied to me truncates before the claims. It ends mid-sentence in the "Detailed Description." I therefore could not read the literal US claim set. My claim overview below is grounded in (a) the patent's own Summary/Description and (b) the European family member EP0990206B1, which uses the same specification and an equivalent claim set. I flag claim numbering as unverified for the US grant.

Bibliographic data

Abstract

A system provides for establishing security in a network that include nodes having security functions operating in multiple protocol layers. Multiple network devices, such as remote access equipment, routers, switches, repeaters and network cards having security functions are configured to contribute to implementation of distributed firewall functions in the network. By distributing firewall functionality throughout many layers of the network in a variety of network devices, a pervasive firewall is implemented. The pervasive, multilayer firewall includes a policy definition component that accepts policy data that defines how the firewall should behave. The policy definition component can be a centralized component, or a component that is distributed over the network. The multilayer firewall also includes a collection of network devices that are used to enforce the defined policy. The security functions operating in this collection of network devices across multiple protocol layers are coordinated by the policy definition component so that particular devices enforce that part of the policy pertinent to their part of the network.

Independent claims — plain-language overview

The patent describes two statutory classes: a system/apparatus claim and method claims. Based on the specification and the EP family member's claim set:

1. System claim (a system for providing security in a network including a set of nodes). A network where the nodes (NICs, repeaters, switches, routers, remote-access gear, etc.) run security functions across multiple protocol layers and are configured by configuration data formatted for each node type. The system has three cooperating elements:

• a topology data store holding (i) what security functions each node runs and (ii) how the nodes interconnect;
• a configuration interface (e.g., a script interpreter / GUI) that receives security policy statements describing policies to be implemented among the nodes; and
• a configuration driver, coupled to the network, the interface, and the topology store, that translates the policy statements into node-specific configuration data formats and distributes it to the nodes over the channels available to each node.

2. Method claim (establishing a firewall system in a network). The mirror-image method: provide topology data (security functions per node + node interconnections); provide security policy statements; then, in response to the topology data, translate those policy statements into configuration data for the security functions; and establish that configuration data in the nodes' security functions. Security functions operate at at least two protocol layers (e.g., data link, network, transport, application).

3. Cut-vertex method claim (an alternative/optimized method). Same starting steps, but the claimed translation targets a "cut vertex set" — the set of policy-capable (active) nodes which, if removed, would isolate the source set of end stations from the destination set. The policy statements are translated into configuration data specifically for the cut-vertex nodes and installed there. A dependent claim narrows this to a minimal cut vertex set (fewest nodes).

Notable dependent/feature concepts (from the specification and EP counterpart claims, mapping to US dependents is unverified): the topology store distinguishing active nodes (can/can be trusted to enforce policy) from passive nodes (cannot or are not trusted); nodes coupled to "external" links; enforcing policy for passive nodes via their linked active nodes; signalling that a rule cannot be enforced when a passive-to-passive path avoids any active node; a policy-language syntax keyed on source, destination, activity, rule, and "Enforced At" location; and configuration data sent to persistent storage local to or remote from the node, followed by a notification causing the node to retrieve the updated policy.

Legal-status / enforcement observations

• The patent is recorded as expired as of 2017-05-29. An expired patent cannot be asserted for ongoing infringement, which is consistent with finding no live 2026 litigation or CAFC appeal.
• Assignment chain on record: 3Com → Hewlett-Packard Company (2010 merger) → Hewlett-Packard Development Company, L.P. (2011/2012) → Hewlett Packard Enterprise Development LP (2015).
• The patent is cited as prior art in later firewall-art families (e.g., EP1119151B1, EP1634175B1, EP1484887 — Microsoft multi-layer firewall work), evidencing its role as foundational art in distributed/multilayer firewalling. It is also cited alongside the Nessett & Humenn paper "The Multilayer Firewall" (NDSS, March 1998).

Explicit uncertainty

• I could not retrieve the literal issued US claim text; the claim overview is reconstructed from the specification and the EP0990206B1 counterpart. Exact US claim numbering, preamble wording, and dependent-claim count should be verified against the USPTO PatentCenter full text (https://patents.google.com/patent/US5968176/en).
• I found no authoritative 2026 CAFC docket for this patent; this reflects the limits of the searches performed and should not be read as a definitive negative.

I'll research litigation involving US patent 5968176. Let me run several targeted searches.

Initial searches returned unrelated content. Let me search patent litigation databases directly.

Let me search patent litigation aggregators and specific docket sources.

Summary of findings on U.S. Patent No. 5,968,176

I could not identify any litigation in which U.S. Patent No. 5,968,176 ("Multilayer firewall system") was asserted. Based on the sources I was able to reach, there is no known infringement suit, declaratory-judgment action, PTAB trial, or ITC investigation involving this specific patent number. Below is what I verified, plus important caveats.

What the patent is (confirmed via the authoritative full text)

• Patent No.: US 5,968,176 A
• Title: "Multilayer firewall system"
• Inventors: Danny M. Nessett; William Paul Sherer
• Original assignee: 3Com Corp (application US 08/865,482, filed 1997-05-29; granted 1999-10-19)
• Priority/family: WO 98/54644 (A1), CA 2291158 (A1), GB 2342020 (B), EP 0990206 (B1), JP 2002-507295 (T)
• Current assignee of record (per Google Patents): HP Inc. / Hewlett Packard Enterprise Development LP (via the 3Com → HP → HPE chain)
• Legal status: Expired – Lifetime (anticipated expiration 2017-05-29)

Litigation research results

Searches of litigation-oriented sources (including court opinions on CourtListener/RECAP, Justia dockets, RPX Insight, and Unified Patents–related materials) returned no case matching 5,968,176. The 3Com patent litigations that surfaced involved different patent numbers and should not be conflated with the '176 patent:

Where '176 does appear (citations, not litigation)

The '176 patent shows up as prior art in other patents — which is citation activity, not enforcement:

• EP 1 634 175 B1 cites US 5,968,176 in its background (a multilayer security/access-policy patent).
• US 10,264,021 B2 (Bansal et al., "Method and apparatus for distributing firewall rules" — the "AppliedTo" enforcement-point rules) lists US 5,968,176 in its references.

Important caveats / limitations

1. I was unable to run exhaustive docket-level searches (e.g., full PACER docket text, Docket Navigator, RPX Insight's per-patent litigation tab, or the Unified Patents case list at portal.unifiedpatents.com/litigation/caselist) before hitting tool limits, and some of those databases are paywalled/proprietary. My negative finding should be treated as "not found in the sources searched," not as a categorical confirmation that no case ever existed.
2. The '176 patent expired in 2017, and it was a 3Com enterprise-networking patent (not part of the widely litigated 3Com "Parallel Tasking" NIC-controller family that passed to Parallel/USEI). Its profile is consistent with a patent that was never asserted in an infringement suit.
3. If you need a definitive, black-and-white answer for a filing or opinion, I recommend confirming against Lex Machina / Docket Navigator, the RPX Insight patent page for 5,968,176 (insight.rpxcorp.com), and the Unified Patents Portal litigation case list filtered to this patent number.

Bottom line: As of this review, no litigation involving US 5,968,176 is known; the most closely related 3Com/HP enforcement activity concerns different patent numbers.

Would you like me to attempt a focused follow-up search specifically on RPX Insight, Lex Machina public pages, or the PTAB/court dockets for the '176 number?

PTAB / AIA Trial Analysis — U.S. Patent No. 5,968,176 ("Multilayer firewall system")

Source hierarchy used: (1) the structured "PTAB proceedings on file" block supplied in this prompt (USPTO Open Data Portal ingest — treated as canonical for the existence of AIA trials); (2) targeted web searches to catch anything ODP has not indexed; (3) the authoritative full patent text. Where I could not confirm something, I say so rather than filling the gap.

---

Proceedings overview

There are zero (0) AIA trial proceedings on file against U.S. Patent No. 5,968,176. The structured USPTO ODP block returns no IPR, PGR, or CBM proceeding for this patent, and my supplemental searches surfaced no petition, institution decision, Final Written Decision, or Federal Circuit appeal attributable to patent 5,968,176. The breakdown is therefore: 0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution denied.

Bottom-line defensive posture for a defendant: the PTAB gives you nothing — and it doesn't need to. The patent's claims are entirely untested at the Board, so "claims cancelled" is not available as a defense. But the patent is recorded as expired — lifetime, with anticipated expiration 2017-05-29, and issued 1999-10-19 from an application filed 1997-05-29. That expiration date, not any PTAB outcome, is the decisive fact: a complaint filed today (2026-09-30) reaches back only to 2020-09-30 under the 35 U.S.C. § 286 six-year damages limitation, a window in which the patent was already dead and no infringement could occur. Any suit on the '176 patent filed today carries a zero-dollar damages ceiling regardless of validity. See "Strategic summary" below for the caveats on that point.

I found no proceeding to report at the per-proceeding level. No proceeding numbers are invented here.

Absence-of-evidence checks performed

Fabrication guard — a live collision risk to flag: several search returns reference a different patent, U.S. 9,560,176 ("the '176 Patent," Centripetal Networks). Filings in Palo Alto Networks, Inc. v. Centripetal Networks, Inc., IPR2021-01521, and the related Centripetal mandamus petition (Fed. Cir. No. 2023-0145 docket line per the 2023-03-23 mandamus petition, https://ipwatchdog.com/wp-content/uploads/2023/03/2-Centripetal-Mandamus-Pet-with-Appendix-2023-03-23.pdf) concern U.S. 9,560,176, a 2017-granted cybersecurity patent. That is not U.S. 5,968,176. The shorthand "'176 patent" in that briefing refers to the Centripetal patent. Anyone pulling these dockets into a chart for 5,968,176 would be creating a false record — I am explicitly separating them.

---

Strategic summary

1. Claim status: everything is UNTESTED; nothing is canceled and nothing is sustained.
Because no AIA trial was ever instituted, there is no claim-level PTAB record for US 5,968,176 — no independent claim cancelled, no dependent claim upheld, no FWD, no adverse judgment, no certificate. As noted in the prior sections of this analysis, the authoritative text supplied to me truncates before the US claim set, so I cannot even enumerate the literal claim numbers with confidence; my earlier summary reconstructed claim structure from the specification and the EP 0 990 206 B1 family member and flagged US claim numbering as unverified. A defendant therefore cannot argue "claim 1 was cancelled," and should not attempt to. The correct framing is: there is no PTAB invalidity finding to point to, because the patent was never challenged.

2. Estoppel landscape: there is none — but the window is closed anyway.
With no FWD, 35 U.S.C. § 315(e)(2) estoppel has never attached to anyone. No petitioner, RPI, or privy is barred from raising § 102/§ 103 grounds in a civil action or before the Office. Conversely, no defendant enjoys a pre-built estoppel benefit either. Any defendant could in principle still file an IPR — the Board has permitted review of expired patents (with Phillips claim construction rather than BRI) — subject to the § 315(b) one-year bar from service of an infringement complaint and the § 325(a) bar if the defendant filed a DJ action first. Practical value of such a petition is low: the patent expired 2017-05-29, so there is no exclusionary right left to attack, and the Board's discretionary-denial tools (§ 314(a), Fintiv-type efficiencies, settled-expectations reasoning in recently designated decisions) would weigh against spending Office resources on a dead patent.

3. Pattern signals: none of the usual ones appear.
No repeat petitioner, no patent-owner PTAB appeal, no defensive-aggregator (Unified Patents et al.) challenge surfaced. That is consistent with the earlier finding of no known district court litigation on this patent and with its profile: a 3Com enterprise-networking patent (application 08/865,482) that was not part of the heavily litigated 3Com "Parallel Tasking" NIC-controller family that passed to U.S. Ethernet Innovations. Its documented footprint is citation-driven, not assertion-driven — e.g., it appears as prior art on the face of later grants such as US 10,264,021 B2 (Bansal et al., "Method and apparatus for distributing firewall rules" — the "AppliedTo" enforcement-point rules) and US 7,624,434 B2 (system for providing firewall capabilities to a communication device), and in the background of EP 1 634 175 B1. That is a signal of foundational prior art status, not of enforcement value.

4. One caveat the PTAB analysis should not be allowed to obscure. The strongest defensive position here is statutory, not administrative: the patent's term ended 2017-05-29, and any complaint filed on or after 2023-05-29 has an empty damages window under § 286. That is a Rule 12 motion, not an IPR.

---

Recommended next steps

• If you have received a demand or complaint citing US 5,968,176: do not build a defense around PTAB outcomes — there are none to cite. Attack on the term instead. Confirm the expiration and the entire chain of maintenance-fee/expiration events on USPTO Patent Center (https://patents.google.com/patent/US5968176/en; Patent Center: https://patentcenter.uspto.gov) and, for the official AIA-trial record, PTAB E2E (https://ptacts.uspto.gov/ptabweb) and the PTAB decisions page (https://www.uspto.gov/patents/ptab/decisions). Then frame the § 286 argument: for a 2026 filing, the recoverable window runs from 2020-09-30 forward, a period in which the patent had already expired, so no recoverable damages exist.
• If you nonetheless need an administrative record for a litigation hold or diligence file: consider a targeted ex parte reexamination research pull and a PAIR/Patent Center "transaction history" download for control numbers beginning 90/ and 95/, since the structured ODP block does not cover reexamination. My search found no reexam, but that is a search-level negative, not a canonical data source.
• If your real interest is the technology, not this patent number: the more valuable use of US 5,968,176 is offensively, as prior art. Its 1997-05-29 priority date and its disclosure of coordinated, policy-driven configuration of distributed enforcement points across multiple protocol layers (see the "Enforced At" / source-destination-activity rule syntax and the cut-vertex-set analysis in the specification) make it strong art against later distributed-firewall and "enforcement point" claiming. That is how it has actually been used to date — as a cited reference, not as an asserted patent.
• Do not, under any circumstances, import the Centripetal '176 (U.S. 9,560,176) PTAB history into this file. Different patent, different owner, different decade. Verify the full seven-digit number before any citation.

Plainest statement of the answer you asked for: there are no AIA trial proceedings on US 5,968,176. The absence is the finding. For a 1997-priority patent that expired in 2017 and was never commercially asserted, that silence is expected rather than surprising.

I'll research the assignment record for US 5,968,176 across the sources specified. Let me run several targeted searches.

Good — I found a concrete reel/frame for the 2015 link. Let me pin down the earlier links' reel/frame numbers and correspondents.

I hit the tool-call limit before I could load the USPTO Assignment Center pages directly (assignment.uspto.gov and assignmentcenter.uspto.gov are not well indexed by the search engine I have, and the direct-page fetches returned nothing). So the reel/frame data below is partial: I have one fully confirmed reel/frame plus one reel/frame that is referenced inside a later corrective assignment. Everything else is dated but reel/frame-unconfirmed. I flag each case explicitly rather than filling gaps with invented numbers.

---

Inventors

No unusual pattern. The "all inventors gone within 12 months → portfolio fire-sale" warning sign is absent: Sherer in particular was still filing at 3Com/its successors into 2013, long after this patent issued. One minor third-party data discrepancy to flag: PatentLeaderboard's table for 5968176 lists only "Danny M. Nessett" as co-inventor, whereas the patent itself names both Nessett and Sherer — a reminder that aggregator inventor tables are unreliable and the patent front page governs.

---

Original assignee

3Com Corporation (Delaware corp.; principal address of record in the merger filings: 350 Campus Drive, Marlborough, MA 01752).

• Primary line of business: enterprise data networking — Ethernet NICs, hubs/repeaters, switches, routers, remote-access/line and packet servers. The patent's own node taxonomy (NIC 15, switch 12, remote access equipment 13, router 14, repeater 16) maps directly onto 3Com's shipping product lines. 3Com later added network security products through its TippingPoint division (per HP's 2010 acquisition release: "network security capabilities through its TippingPoint portfolio").
• Did they ship a product embodying the claims? Partially / indirectly. 3Com shipped the constituent device classes the claims address, but I found no evidence 3Com ever commercialized the full "pervasive multilayer firewall" system as a single product, and the distributed-policy-management architecture reads as an architecture patent rather than a product SKU.
• Current status: Acquired and dissolved as an independent company. HP announced the $7.90/share (~$2.7B enterprise value) deal on 2009-11-11; MOFCOM approval 2010-04-08; HP completed the acquisition 2010-04-12 (HP's FY2010 10-K: aggregate purchase price $3.3B, ~$1.3B goodwill, $987M purchased intangibles). 3Com ceased independent existence; the 3Com brand was folded into HP Networking (H3C retained as a China brand).

---

Assignment timeline

Each entry is dated from the Google Patents legal-events record for US 5,968,176 (authoritative text in this analysis). Where reel/frame is known I state it; where I could not retrieve it I say so.

1. 1997-05-29 (executed) / recorded 1997-05-29 — Reel/frame not retrieved

   • Conveyance: Assignment of assignors' interest (original filing assignment)
   • Assignor: Sherer, William Paul; Nessett, Danny M. (individually)
   • Assignee: 3Com Corporation
   • Correspondent: not retrieved (Assignment Center/PEDS page not loadable in this session). Likely 3Com's then-IP department or outside prosecution firm — I will not guess a name.
   • Context: Original inventor-to-company assignment at filing — standard employment/IPO assignment, not a transfer of portfolio.

2. 2010-07-06 (recorded) — Reel/frame not retrieved

   • Conveyance: Merger ("SEE DOCUMENT FOR DETAILS")
   • Assignor: 3Com Corporation
   • Assignee: Hewlett-Packard Company
   • Correspondent: not retrieved.
   • Context: Internal corporate acquisition — 3Com became an HP subsidiary, so the whole portfolio (incl. '176) moved by operation of the merger.

3. 2010-07-15 (recorded) — Reel/frame not retrieved

   • Conveyance: Corrective assignment ("TO CORRECT THE SEE ATTACHED")
   • Assignor: 3Com Corporation
   • Assignee: Hewlett-Packard Company
   • Correspondent: not retrieved.
   • Context: Administrative correction of the merger recording — same event, paperwork fix, not a new transfer.

4. 2011-12-06 (recorded) — Reel/frame 027329/0001 and 027329/0044 (established via the later corrective assignment, which expressly recites "PREVIOUSLY RECORDED ON REEL 027329 FRAME 0001 AND 0044")

   • Conveyance: Assignment of assignors' interest
   • Assignor: Hewlett-Packard Company
   • Assignee: Hewlett-Packard Development Company, L.P.
   • Correspondent: not retrieved on this link; note the recurring HP IP-admin address seen elsewhere in the HP chain is Hewlett-Packard Company, Records Manager, Intellectual Property Administration, P.O. Box 272400, Fort Collins, CO 80527-2400.
   • Context: Internal corporate reorganization — HP parked the portfolio in its Development Company L.P. IP-holding subsidiary.

5. 2012-05-01 (recorded) — Reel/frame not retrieved (corrects 027329/0001 and 027329/0044)

   • Conveyance: Corrective assignment ("PREVIUOSLY RECORDED ON REEL 027329 FRAME 0001 AND 0044")
   • Assignor: Hewlett-Packard Company
   • Assignee: Hewlett-Packard Development Company, L.P.
   • Correspondent: not retrieved.
   • Context: Clean-up of the 2011 reorg recording — same transfer, corrected paper.

6. 2015-10-27 (executed) / recorded 2015-11-09 — Reel/frame 037079/0001

   • Conveyance: Assignment of assignor's interest ("SEE DOCUMENT FOR DETAILS")
   • Assignor: Hewlett-Packard Development Company, L.P.
   • Assignee: Hewlett Packard Enterprise Development LP, 11445 Compaq Center Drive West, Houston, Texas 77070
   • Correspondent: Hewlett Packard Enterprise, 3404 E. Harmony Road MS 79, Fort Collins, CO 80528
   • Context: Internal corporate spin-off/spilt — the 2015 HP split, moving the portfolio into HPE. Note: reel 037079/0001 is a bulk recording covering ~11,870 properties (I retrieved it from a PTAB/petition exhibit at ptacts.uspto.gov); the execution/recordation dates match the '176 legal event exactly, so it almost certainly includes this patent, but I did not view a '176-specific page confirming the property count. This is a high-confidence inference, not a direct read.

Caveat on the whole section: I could not open a live Assignment Center result set for 5968176. If you need certified reel/frame for entries 1, 2, 3 and 5, verify at https://assignmentcenter.uspto.gov (search "5968176" → Reel/Frame tab) — the underlying records exist (Google Patents legal events corroborate every date), I simply couldn't reach the detail view.

---

Timeline diagram

timeline
    title Ownership of US 5968176
    1997 : Filed and assigned to 3Com Corp
    2010 : 3Com acquired by Hewlett-Packard
         : Merger recording corrected
    2011 : Assigned to HP Development Company LP
    2012 : Corrective assignment recorded
    2015 : Assigned to HP Enterprise Development LP
    2017 : Patent expired

---

NPE / troll-pattern signals

1. Shell-entity transfer — Not present. Every assignee in the chain is a Hewlett-Packard-family operating entity (3Com Corp → Hewlett-Packard Company → Hewlett-Packard Development Company, L.P. → Hewlett Packard Enterprise Development LP). No "IP/Licensing/Holdings/Ventures" suffix, no Delaware/Texas single-purpose LLC, no registered-agent address. Entries 1/2/4/6 (1997-05-29; 2010-07-06; 2011-12-06; 2015-11-09) are all intra-corporate.

2. Known asserter in the chain — Not present. No Acacia, Marathon, IV, IPNav, Wi-LAN, Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Erich Spangenberg entity, etc., appears anywhere in the recorded chain. Current assignee per Google Patents and Unified Patents' patent page: HP Inc. / Hewlett Packard Enterprise Development LP — operating companies.

3. Repeat correspondent across the chain — Unclear / effectively not present. The only correspondent I retrieved is "Hewlett Packard Enterprise, 3404 E. Harmony Road MS 79, Fort Collins, CO 80528" on the 2015-11-09 link (reel 037079/0001). A closely related corporate IP-admin correspondent recurs across the broader HP-family recordings (e.g. "Hewlett-Packard Company, Records Manager, Intellectual Property Administration, P.O. Box 272400, Fort Collins, CO 80527-2400" appears on the adjacent Compaq→HP change-of-name recording 015000/0305). This is HP's own in-house IP department recurring, which is a benign signature — the classic NPE tell is the same private attorney shepherding unrelated-looking LLCs, and that is absent here. Single data point; not a finding.

4. Cascading transfers — Not present. Transfers are 1997, 2010, 2011, 2015 — spaced years apart, all corporate reorgs/mergers, none a <24-month chain of assignees sharing an address/principal.

5. Pre-litigation transfer — Not present. No infringement suit naming US 5,968,176 exists (consistent with the earlier Litigation section of this analysis), so there is no litigation date to measure a 6-month-preceding transfer against.

6. Bankruptcy fire-sale — Not present. 3Com was acquired in a solvent $2.7B all-cash merger, not a Chapter 7/11 sale.

7. Privateering — Not present for '176 (but worth flagging as adjacent portfolio color). Two other 3Com-origin families did travel to assertive non-practicing entities: (a) Parallel Technology LLC (Tyler, TX) bought 3Com's Ethernet-technology patent portfolio (~35 patents) in May 2009 with a revenue-share enforcement agreement, and sued 3Com in Delaware Chancery on 2010-01-07 to block the HP deal — but this was the Ethernet/NIC portfolio, and no source ties the '176 firewall patent to that sale; (b) HP later transferred 3Com-origin US 6,205,149 and US 5,978,951 to Plectrum LLC in September 2016, which sued Cisco and Facebook (Ars Technica, Feb 2017). Again, different patents — no evidence '176 was among them. So the family shows HP monetizing select 3Com patents through NPEs, but '176 itself did not leave the HP/HPE house.

8. Defensive aggregator — Not present. The chain terminates at Hewlett Packard Enterprise Development LP, an operating company — not RPX, AST, LOT, Unified Patents, or OIN.

---

Verdict

Defensive / non-asserting.

Justification: the full recorded chain — 1997-05-29 (inventors → 3Com), 2010-07-06 + 2010-07-15 (3Com → Hewlett-Packard, merger and its correction), 2011-12-06 at reel 027329/0001 and 027329/0044 + 2012-05-01 correction (Hewlett-Packard → Hewlett-Packard Development Company, L.P.), and 2015-10-27/2015-11-09 at reel 037079/0001 (HP Development Company, L.P. → Hewlett Packard Enterprise Development LP) — is an unbroken sequence of corporate reorganizations inside one operating-company family, with no LLC transfer, no known asserter, no pre-suit transfer, and no assertion. Definitional caveat: the prompt defines "Defensive / non-asserting" as termination at a defensive aggregator, and HPE is a product-shipping operating company rather than an RPX/AST-style aggregator — so the label is being applied loosely to mean "held and not asserted by a large operating company." If you prefer a strict reading, the only alternative among the five choices is "Insufficient data," and that would be justified solely on the ground that I could not retrieve certified reel/frame for four of the six recordings — not because the ownership picture is actually unclear.

Verify the record at the USPTO Assignment Center: https://assignmentcenter.uspto.gov/ (search patent number 5968176) or the legacy view at https://assignment.uspto.gov/patent/index.html.

Two contradictions/flags against the earlier sections of this analysis: (1) the earlier Patent-summary section said the family shows "no recorded post-issuance assignments other than the corporate chain" — that is confirmed, but I can now add the actual reel/frame anchors (027329/0001; 027329/0044; 037079/0001) and the HPE in-house correspondent that the earlier section did not have; there is no conflict, only added granularity. (2) The earlier summary listed the 2015 assignee only as "Hewlett Packard Enterprise Development LP" with no execution date; the confirmed execution date is 2015-10-27, recorded 2015-11-09 — update the earlier bibliographic table accordingly if it is carried forward.

I'll research the prior art references cited against US 5,968,176. Let me run several targeted searches.

I now have the patent's complete front-page "References Cited" list. Let me verify details on each cited reference.

Let me verify the remaining three cited U.S. patents and the key non-patent reference.

Prior-Art Analysis — US 5,968,176 ("Multilayer firewall system")

0. Identification (literal, no auto-correction)

I located the requested record — US 5,968,176 (grant number displayed as 5,968,176 / US5968176A), which is the "Multilayer firewall system" patent. I did not substitute or conflate similar numbers.

Correction to the earlier "Patent summary" section: that section flagged the U.S. claim set as unverified and reconstructed it from EP 0990206 B1. The literal U.S. claim set is now confirmed — US 5,968,176 has 70 claims, with 9 independent claims (1, 21, 22, 25, 26, 27, 29, 43, 63) and 61 dependents. That resolves the earlier uncertainty. (Source: the grant text reproduced at https://uspto.report/patent/grant/5968176.)

Because the independent claims are the ones a § 102 reference must meet in full, I use them as the comparison anchor below. Their essentials:

• Claim 1 (system) — nodes of a plurality of network-device types running security functions responsive to type-adapted configuration data; a topology data store (security functions and node interconnections); a configuration interface coupled to it receiving security policy statements; a configuration driver coupled to network/interface/store that translates policy statements into configuration data for the several node types and conveys it to the nodes, with security functions across multiple protocol layers coordinated so particular device types enforce the pertinent part of the policy.
• Claim 21 / 22 (system) — adds topology data distinguishing active nodes (can enforce) from passive nodes (cannot or not trusted); claim 21 also "external" links.
• Claim 25 (system) — script-language syntax (source set, destination, activity, rule) + driver identifies policy statements that cannot be enforced.
• Claim 26 (system) — topology data structures per node: network-layer addresses, MAC addresses, user identifiers, trust flag, enforceable policy type, connections.
• Claim 27 (system) — cut-vertex set of policy-capable nodes that, if removed, isolate source set from destination set (claim 28: minimal).
• Claim 29 (system) — combined topology data structures + script syntax.
• Claim 43 (method) — provide topology data, provide policy statements, in response to topology data translate into configuration data, establish at nodes; topology data structures include trust flag and enforceable-policy-type.
• Claim 63 (method) — cut-vertex method.

---

1. The complete citation set

The entire "References Cited" list on the face of US 5,968,176 comprises five U.S. patents and a set of non-patent literature. That is the whole of what the USPTO printed against this patent; there are no foreign patent documents on the U.S. front page. Cross-check: the EPO search report for the family member EP 0990206 cites US 5,606,668 A (Shwed) as category [A] ("technological background") — i.e., the counterpart office likewise treated it as background, not as a novelty-destroying reference (http://data.epo.org/gpi/EP0990206A4).

1.1 U.S. patent references cited

Date-analysis note (important under pre-AIA § 102, which governs a 1997 filing): only US 4,881,263 and US 5,577,209 are printed publications more than one year before 1997-05-29 and therefore squarely § 102(b) art. US 5,606,668 was published 1997-02-25 — under one year before filing — so it is § 102(a)/102(e) art keyed to its 1993-12-15 filing date, not § 102(b). US 5,740,375 and US 5,828,893 issued after the '176 filing date and can only be § 102(e) art as of their earlier filing dates.

1.2 Non-patent literature cited (the more probative art here)

---

2. Reference-by-reference § 102 assessment

The framing that matters: a § 102 anticipation requires one reference to disclose every element of the claim. None of the five patents was cited by the examiner as a novelty rejection; the EPO counterpart tags US 5,606,668 as category [A]. My assessment is therefore "potentially anticipates / potentially material," with the specific element(s) each reference is missing identified, so you can see where a § 103 combination argument (rather than pure § 102) would be needed.

① US 4,881,263 (Herbison/DEC, 1989) — § 102(b).

• Discloses: node-attached encryption controllers + KDC distributing keys; header fields (source/dest node address, protocol type) carried for the encrypted frame; audit of "auditable events."
• Potentially anticipates: claims 6, 8 (authentication/authorization as "security functions"), and — weakly — the "protected communications" limb that the specification folds into the multilayer firewall. Its protocol-type field and per-node controller keyed to node address touch the "type-adapted configuration data" idea, but there is no topology store, no policy-language translation, and no multi-layer coordination.
• Cannot anticipate: independent claims 1, 21, 22, 25, 26, 27, 29, 43, 63 — no topology data store, no configuration interface receiving policy statements, no node-type translation of policy.

② US 5,577,209 (Boyle/ITT, 1996) — § 102(b). This is the strongest patent reference.

• Discloses: a security manager connected to each SNIU and controlling their "operation and configuration"; per-node security functions (integrity, separation of data types, access control, authentication, user identification/accountability); a defined set of classification/access attributes enforced in network devices.
• Potentially anticipates: claim 1 (security functions in a set of network nodes, centrally configured, coordinated) and especially claims 21, 22, 26, 29 in their "trusted / not-trusted" and "topology data structures (addresses, user identifiers, trust flag, type of policy it can enforce, connections)" aspects — Boyle's SM architecture ensures "user accountability, configuration management, security administration, and cryptographic key management among the SNIUs." A § 102 challenge on claim 26 by Boyle is at least arguable.
• Likely missing for full anticipation of claim 1: (i) a topology data store of node interconnections (Boyle is hub-and-SNIU, not a general graph), (ii) scripted policy-language translation into differing device-type formats, and (iii) enforcement across multiple protocol layers (Boyle's SNIU operates at the session layer). Those gaps push any invalidity theory toward § 103.

③ US 5,606,668 (Shwed/Check Point, filed 1993-12-15; issued 1997-02-25) — § 102(a)/(e).

• Discloses: high-level security rules entered via GUI at a system administrator → packet filter generator translates rules into packet-filter code → code distributed and installed on filter modules at "strategic points in the network" → every packet inspected and accepted/dropped; control module + storage for logs.
• Potentially anticipates: the configuration-interface-plus-configuration-driver core of claim 1, and the GUI-entry aspect underlying claim 16 ("script interpreter which interprets a script language")/claims 17–18 (source/destination/activity/rule syntax) if the GUI rule model is read broadly. It is also the natural reference for the "different devices get different filter code" notion and for claim 19/39 (configuration data sent to storage and executed).
• Likely missing for full anticipation of claim 1: a topology data store that records both the security functions running at each node and the node interconnections, and explicit coordination across multiple protocol layers with the policy "pertinent to the associated part of the network." Shwed distributes code to points but does not describe partitioning a global policy by network graph position. Again this reads as a § 103 combination reference (e.g., Shwed + Guttman + Boyle), not a clean § 102 reference.

④ US 5,740,375 (Dunne/Bay Networks, filed 1996-02-15; issued 1998-04-14) — § 102(e) only.

• Discloses: intermediate-node destination-address replacement to forward packets.
• Potentially anticipates: at most the "transformational filtering" / address-translation concepts the specification mentions and the proxy-style forwarding aspect relevant tangentially to claim 5 (application-layer filtering). No independent claim is remotely met. Its presence in the list is peripheral.

⑤ US 5,828,893 (Wied/Motorola, filed 1992-12-24; issued 1998-10-27) — § 102(e) only.

• Discloses: communication mediated between a trusted and an untrusted computer system.
• Potentially anticipates: the trusted-vs-untrusted node dichotomy relied on by claims 21, 22, 34, 49 ("active nodes … and passive nodes which are incapable of enforcing, or not trusted to enforce, a security policy") and the "whether the node is trusted to enforce security policy" topology field of claims 26, 43, 64. As with the others, it supplies a limitation, not the whole claim.

---

3. Ranking — "most relevant prior art" for 5,968,176

1. US 5,606,668 (Shwed / Check Point FireWall-1) — the closest patent reference to the "high-level policy → translated → distributed to enforcement points" architecture of independent claim 1. Its § 102(e)/102(a) status (1993 filing) makes it the reference most likely to be used.
2. US 5,577,209 (Boyle / ITT) — the closest patent reference to the centrally-managed set of security-enabled network nodes and to the trusted/untrusted and topology-data-structure dependent claims (21, 22, 26, 29, 34).
3. Guttman, "Filtering Postures: Local Enforcement for Global Policies" (May 1997) — the closest non-patent reference to the core inventive concept (global policy realized by dispersed local enforcement), though its timing (just weeks before the 1997-05-29 filing) and printed form should be checked for § 102(b) qualification.
4. US 5,828,893 (Wied / Motorola) — material only for the trusted/untrusted limitation.
5. US 4,881,263 (Herbison / DEC) — protected-communications/authentication background (claims 6, 8).
6. US 5,740,375 (Dunne / Bay Networks) — peripheral (address-replacement forwarding).

Bottom line: the five cited U.S. patents are, individually, background/limitation references. The features that made the '176 claims patentable — a topology data store recording node interconnections, partitioning a global policy into node-specific, device-type-formatted configuration data, multi-protocol-layer coordination, the active/passive model, and the cut-vertex-set methods (claims 27/28, 63/70) — are not fully found in any single one of them. Any invalidity attack grounded in this citation list would most plausibly be a § 103 combination (e.g., Shwed's translation-and-distribution engine + Guttman's local-enforcement-of-global-policy + Boyle's managed trusted/untrusted SNIU topology) rather than pure § 102 anticipation. That is also consistent with the fact that no rejection of the '176 claims on any of these references appears to have been sustained — the patent issued with all 70 claims, and it is now expired (anticipated expiration 2017-05-29), so the citations stand as art, not as an enforcement vehicle.

---

4. Caveats (explicit)

• I retrieved the grant's front-page "References Cited" (five U.S. patents + the NPL list above) and the full U.S. claim text. I did not obtain the examiner's actual PTO-892 / PTO-1449 forms or the paper Official Actions, so I cannot state which of these references the examiner cited versus which the applicant disclosed, nor whether any reference was used in a rejection that was later overcome. Treat the tables above as the citation universe, with my § 102 mapping as analysis, not a recorded USPTO finding.
• My "potentially anticipates" labels identify the claim(s) each reference most plausibly touches; they are not assertions that anticipation in fact exists. Where a reference lacks an element, I say so, and the correct statutory vehicle is § 103.
• Date-sensitive status (102(a)/(b) vs. 102(e)) reflects pre-AIA § 102, which applies to this 1997 application. Two of the cited U.S. patents (US 5,740,375; US 5,828,893) and two of the Check Point items (Oct. 1997; 1998) cannot be § 102(a)/(b) art because of their dates — verify before relying on them.
• If you need the examiner's precise citation treatment, the authoritative sources are the USPTO PatentCenter file wrapper for application 08/865,482 and the EPO Global Dossier for EP 0990206 (which shows US 5,606,668 marked category [A]).

Would you like me to build a limitation-by-limitation claim chart (claim 1 and claim 43 against Shwed and Boyle) or to pull the examiner's search-report categories for the EP/GB family members to corroborate which references were treated as anticipatory versus background?

I'll research the prior-art landscape for this patent, starting with the patent's own cited references and the key technology families that existed before the 1997-05-29 priority date.

I have strong leads. Let me ground the key pre-1997 references — the examiner-cited Shwed patent, VLAN/802.10 layer-2 security, and network-management topology databases.

Obviousness Analysis — U.S. Patent No. 5,968,176 ("Multilayer firewall system") under 35 U.S.C. § 103

Note on the record I am working from. The authoritative full text supplied for US 5,968,176 truncates inside the Detailed Description and therefore contains no "References Cited" list. The only prior-art identifiers literally present on the page are:

• Prior art keywords: nodes, network, security, security policy, configuration
• Two publications cited by the inventors in the background: Chapman et al., "Building Internet Firewalls," O'Reilly & Associates, September 1995, and Semeria, "Internet Firewalls and Security," 3Com Technical Report, 1996.

Because the US reference list is missing from the supplied text, I supplemented it with the search-report citations of the same family member, DE 69836271 T2 / EP 0 990 206 B1 (same priority, US 08/865,482), which surfaced in search: US 4,881,263 A (Digital Equipment Corp.), US 5,577,209 A (ITT), US 5,828,893 A (Motorola), US 5,606,668 A (Check Point Software), US 5,740,375 A (Bay Networks). I flag these as family search-report citations retrieved from a secondary page — they are not confirmed from the US "References Cited" section, which I could not read. Two of my planned searches (802.10/Soriano; OpenView topology databases; pre-1997 "distributed firewall") did not return before I hit tool limits, so those specific pins are stated with lower confidence.

---

1. Governing framework

• Critical date: 1997-05-29 (filing = priority; no earlier priority claimed). This is a pre-AIA patent; §§102/103 as amended by the America Invents Act do not apply. Prior art status turns on §102(a)/(b)/(e) relative to 1997-05-29.
• Obviousness standard: KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007) governs any present-day validity analysis — predictable combinations of known elements for their known purposes are obvious, and a "finite number of identified, predictable solutions" evidences obviousness.

1.1 A gatekeeping point many secondary sources get wrong

Three items frequently cited "around" this patent are post-dating and therefore NOT §103 prior art against the 1997-05-29 date:

So although Bellovin's "distributed firewall" is the modern canonical ancestor of this idea, it post-dates the '176 filing. The '176 patent's own priority is what makes it the earlier document. This cuts against using Bellovin/DEN/COPS as invalidating art, and it also means the strongest invalidating art must come from the Check Point / VLAN / bridge-filtering / network-management cluster that actually existed in 1993–1997.

1.2 Person of ordinary skill in the art (POSITA)

A POSITA here would be a network-security engineer with ~2–4 years of experience designing or administering packet-filtering firewalls, IP routers/switches, and SNMP-based network management — i.e., someone who knew (a) how firewalls filter at network/transport layers, (b) how LAN switches/bridges filter at the MAC layer, and (c) how management stations discover and configure devices.

---

2. The claim set to be analyzed

Per the previously generated section (reconstructed from the specification and the EP 0 990 206 B1 counterpart, since the US claims are not in the supplied text), the independent claims are:

• System claim: topology data store (node security functions + interconnections) + configuration interface (receives security policy statements) + configuration driver (translates statements into node-format-specific configuration data and sends it over each node's available channel).
• Method claim: provide topology data → provide policy statements → translate in response to the topology data into configuration data → establish in the nodes' security functions; security functions at ≥2 protocol layers.
• Cut-vertex method claim: translation targets the cut vertex set (active nodes whose removal isolates source set from destination set), and a dependent narrowing to a minimal cut vertex set.

Dependent themes: MAC-layer filtering parameters; IP/network-layer filtering; TCP/transport and higher-layer (auth/authz/audit) configuration; script-language interpreter with GUI; active vs. passive node designation; "external" node; enforcement for passive nodes via their linked active nodes; signalling an unenforceable rule; the source / destination / both / intermediate ("Enforced At") location field; and persistent configuration store (local or remote) + notification delivery.

---

3. Prior-art references available on this record

---

4. Mapping claim limitations to the art

4.1 System claim (independent claim 1 class)

Result: every element is disclosed; the only arguable gap is the unified "topology data store" with per-node security-function capability data — filled by the admitted network-management art. Motivation is supplied by Shwed/FireWall-1 themselves ("strategic points," "Scope" per gateway): to compile and place rules correctly you must know where devices are and what they can enforce.

4.2 Method claim (multi-layer translation)

Combination: Shwed '668 + Chapman + Soriano (or 802.10). Shwed + Chapman teaches translation of high-level rules into device code; Soriano/802.10 supplies the layer-2 (MAC) enforcement leg so that the "≥2 protocol layers" recitation is met (L2 bridge/Soriano + L3 router/Shwed + L4/application/Chapman). Motivation: the '176 specification's own stated rationale — offloading routers and avoiding chokepoints — is a performance rationale, and performance-driven distribution of filtering to NICs/switches/repeaters is precisely the design goal articulated in the VLAN/bridge and 3Com literature. Under KSR, arranging known filtering functions across known layers of known devices to reduce load on a bottleneck is a predictable use of prior-art elements for their established purposes.

4.3 "Enforced At" (source / destination / both / intermediate)

This is the strongest obviousness ground available, because Check Point FireWall-1's rule model is nearly a one-to-one map:

FireWall-1's "one policy for all" model, with "pieces of the policy set wherever appropriate" (Network World, June 1, 1998, describing the v3.0 approach), is the same partitioning concept claimed. A POSITA would adopt the "Scope"/location field as a matter of routine design to avoid re-entering and re-managing the same rule on each device.

4.4 Active vs. passive nodes; enforcing for passive nodes via active nodes; "rule cannot be enforced"

• Active/passive = the well-known question of whether a device can be programmed to filter. Shwed notes routers merely accept "programming script tables" and some devices cannot host a filter at all; Motorola '893 (trusted/untrusted partitions) and ITT '209 (multi-level) show that trust/capability differentiation of network elements was known.
• "Cannot be enforced" signalling is ordinary reachability analysis — determining whether a passive path bypasses all enforcement points is a graph reachability query that a network-management system already performs. A POSITA performing topology-driven rule compilation would necessarily detect and report the impossible placement.
• Enforcement at active nodes associated with passive nodes is the direct reading of Shwed's "packet filter modules located in strategic points" combined with the recognized inability of legacy devices to filter (a problem the '176 background itself raises).

4.5 Cut vertex set / minimal cut vertex set

This is the most defensible limitation because it names a specific graph structure rather than a generic "place filters strategically." Analysis:

• The concept of a cut vertex / separating set and the minimum cut is classic, textbook graph theory (Menger's theorem, 1927; Ford–Fulkerson max-flow/min-cut, 1956). It is a known technique.
• The problem to which it is applied — "which nodes must I instrument so that no traffic can go from A to B uninspected?" — is the same problem Shwed/FireWall-1 address by placing filters at gateways on the path.
• Under KSR, applying a known graph algorithm to a known network-security placement problem to obtain its predictable result (fewest enforcement points that isolate source from destination) is obvious provided the prior art or the POSITA's common knowledge would have motivated minimizing the number of enforcement points. The record supplies that motivation: the patent itself claims "[t]he invention enables reductions in unnecessary redundancy," and the well-documented prior-art concern is chokepoint overhead and per-device configuration burden.

Caveat / possible nonobviousness argument: if the only motivation were the patent's own, i.e., if no pre-1997 reference recognized "minimize the number of enforcement points while guaranteeing isolation," an argument could be made that the specific cut-vertex formulation was not obvious. But: (i) the '176 application has no secondary-considerations (objective indicia) evidence of record, and it is expired (2017-05-29), so no ongoing enforcement; and (ii) the problem was squarely recognized. On balance, the cut-vertex limitation is weak but not frivolous as a validity hook.

4.6 Persistent store + notification (FIG. 5)

Sending new config to a persistent store and then notifying a node to fetch it is standard network practice: BOOTP/TFTP boot loads, with a signal to reboot/re-read — precisely the mechanism the '176 specification itself describes for its own NIC BootROM discussion. Devices that "have persistent storage" vs. "do not" is a routine capability distinction. Obvious on the face of plain device-management practice and the Shwed distribution model.

---

5. Consolidated grounds of rejection

Ground 1 — §103 over Shwed '668 in view of FireWall-1 (and the SNMP/RMON topology-management art): renders the system claim and multi-layer method claim obvious. Shwed supplies rule-translation-to-device-code and distribution to "strategic points," including router script tables; FireWall-1 supplies the per-rule Scope location field and enterprise-wide policy partitioning to multiple heterogeneous enforcement modules (routers, switches, remote-access servers); SNMP/RMON-class management supplies the topology database the '176 specification admits is usable.

Ground 2 — §103 over Shwed '668 + Chapman + Soriano (or 802.10): supplies the multi-protocol-layer recitation (L2 from Soriano/802.10; L3/L4/application from Shwed/Chapman).

Ground 3 — §103 over Ground 1 + Motorola '893 / ITT '209: supplies active/passive (trusted/untrusted) differentiation and multi-level enforcement, plus enforcing for incapable devices via capable neighbors.

Ground 4 — §103 over Ground 1 + textbook min-cut graph algorithms (Menger/Ford–Fulkerson) as applied to firewall placement: renders the cut vertex / minimal cut vertex claim obvious as a predictable application of a known technique to the recognized problem.

Ground 5 — §103 over Ground 1 + routine network-device configuration practice (TFTP/SNMP/RMON; BOOTP/TFTP boot): renders the persistent-store-plus-notification limitation obvious.

Motivation-to-combine, stated generally: (i) distribute filtering to relieve bottleneck routers — articulated in the '176 background and in the 3Com/VLAN literature; (ii) avoid redundant, per-device rule re-entry — the express selling point of FireWall-1's "one policy for all"; (iii) accommodate legacy/incapable devices — a problem both Shwed and the '176 background acknowledge; (iv) minimize enforcement points — a straightforward cost/performance optimization. These are KSR-adequate rational motivations, all grounded in pre-1997 documents.

---

6. Where the patent likely survives §103

1. The cut-vertex / minimal-cut-vertex formulation (§ 4.5) — the only limitation that is a named structural computation rather than a generic placement; it could withstand challenge absent clear pre-1997 art applying min-cut to firewall placement.
2. The unified topology data store carrying per-node security-capability metadata (not merely topology) — but this is substantially undercut by the specification's own admission that network-management tools can supply the topology, and by the fact that Shwed/FireWall-1 require knowing each device's enforceability.
3. "Enforced At" as a first-class policy-language field — but FireWall-1's Scope field makes this a very hard position to hold.

Weakest limitations (most clearly obvious): the "Enforced At" field; persistent-store-plus-notification; multi-layer enforcement coverage.

---

7. Explicit uncertainties and verification steps

• The US "References Cited" list is not in the supplied text. Several references I relied on as family search-report citations (US 5,577,209; US 5,828,893; US 5,740,375; US 4,881,263; US 5,606,668) were retrieved from the DE 69836271 T2 / EP 0 990 206 B1 family page; I could not confirm they appear on the face of the US grant. Verify against USPTO PatentCenter / the US front page.
• I did not confirm the historical availability dates/pagination of Soriano et al. (IEEE 1992) or of an IEEE 802.10 SILS document suitable as a printed publication — my search was cut off by tool limits. Treat the 802.10 limb as medium confidence pending verification.
• The literal issued US claim text is still unverified (carried over from the prior summary). The claim-scope analysis here tracks the EP 0 990 206 B1 counterpart and the specification. Confirm exact US claim numbering/preamble before relying on any ground.
• Prior-art dates to double-check: FireWall-1's per-rule "Scope" field and whether it predates 1997-05-29 (it is documented in the 1997 20-F and v3.0/v4.0 materials; a 1996 datapoint would strengthen it). Soriano and Shwed both pre-date comfortably.
• No litigation or PTAB challenge to '176 is known (per the earlier section). The patent expired 2017-05-29, so this analysis is of historical/validity-interest rather than forward-looking invalidity exposure.

Bottom line: US 5,968,176 is a pioneering-in-conception but largely predictable-in-implementation patent. Its independent system and method claims map closely onto Shwed '668 + Check Point FireWall-1 + the admitted VLAN/RMON network-management art, and its most distinctive policy-language feature ("Enforced At") is nearly anticipated in function by FireWall-1's Scope field. The cut-vertex / minimal-cut-vertex claim is the patent's strongest validity redoubt, but it rests on applying textbook min-cut graph theory to a recognized firewall-placement problem — a KSR-vulnerable position absent objective indicia of nonobviousness, of which the record shows none.