US 6226372

I'll search for the patent and any related litigation/docket activity.

Let me pull the full claim set and check for any 2026 CAFC activity specifically naming this patent.

I have solid identifications. Let me try to retrieve the complete claim sets (independent claims) and confirm no 2026 CAFC docket exists.

US Patent 6,226,372 B1 — Analyst Summary

Scoping note up front: Covers exactly US 6,226,372 B1 (application 09/457,494). No similar-numbered patents substituted. Two caveats are flagged at the end — one on an anomaly inside the claim set, and one on the "CAFC 2026 docket" question.

---

1. Bibliographic Data (from the patent face, Google Patents, and FreePatentsOnline)

---

2. Abstract (verbatim, as printed)

"A system and method for implementing a fully integrated and cooperative telecommunications firewall/scanner that can be deployed either as a standalone device, or over a large-scale distributed client-server architecture is described. In addition to providing enhanced telecommunications firewall and scanner security capabilities, the integrated telecommunications firewall/scanner provides the capability to ensure implementation of a corporate-dictated security structure, and event visibility and report consolidation requirements, across a globally-distributed enterprise, using policy-based enforcement of a Security Policy. In the most basic configuration, the integrated firewall/scanner performs continuous security access monitoring and control functions, keyword and content monitoring and control functions, and remote access authentication, initiating coordinated vulnerability assessments, as well as automatic synchronous adjustments to the Security Policy in response to the vulnerability assessment results. Additionally, firewall and scanner actions, assessment results, and responses can be consolidated in detailed or summary reports for use by security administrators for trend analysis and security posture decision-making. The same Security Policy is used by both the firewall and the scanner components of the integrated firewall/scanner during both their cooperative and independent operations."

---

3. Plain-Language Overview of the Independent Claims

The patent carries 71 claims, with independent claims at 1, 16, 27, 46, 50, 54, 64 and 70 (a further independent claim may sit at or near claim 36 — see uncertainty note). Conceptually they fall into four families: (A) core integrated firewall+scanner systems/methods, (B) distributed client / management-server / line-sensor / dialer architectures, (C) an interface-sensor (CTI) variant, and (D) multi-tier "required vs. optional rule" hierarchy claims.

Claim 1 — Integrated telephony firewall and scanner system (means-plus-function).
An integrated telephony firewall-plus-scanner system that controls and logs access between an enterprise's end-user stations and their circuits into the PSTN, across many extensions. The system includes means for defining a Security Policy made of (i) a security rule base whose rules specify actions based on at least one attribute of a call on an extension, and (ii) a results response policy whose rules specify actions based on the results of a vulnerability assessment ("VA"), plus groups of extensions. Dependent claims 2–11 add: policy updates by moving an extension between groups; the specific group taxonomy (voice-only, secure modem, insecure modem, unauthorized modem); VA by penetration attempt; VA results indicating penetration success/failure; profile-building in response to a VA request; call attributes (call-type, date, time, duration, station extension, inbound number, outbound number dialed); and rule actions (permit, deny, redirect, log, notify).
Caveat: the full verbatim body of claim 1 (the "means for detecting…", "means for sending a VA request…", "means for updating the security policy…" elements) was not returned intact in the sources I could retrieve; the text above reflects the portion that is verbatim plus the dependent-claim structure, which strongly implies those elements.

Claim 16 — Method of implementing an integrated telephony firewall and scanner system.
The method counterpart: define a Security Policy (rule base + results response policy + groups); detect a call on an extension and determine its attributes; perform actions per the security rules; when the rules so dictate, send a VA request; perform the VA on the extension and generate VA results; and perform actions based on the VA results in accordance with the results response rules defined for that extension. Dependent claims 17–26 (including claim 26, confirmed dependent on claim 16) add permitted/denied-call actions, notification, logging, and policy updating.

Claim 27 — Distributed system claim (firewall/scanner client + management servers + dialer).
A system with: a firewall/scanner client that defines the Security Policy (security rule base, results response policy, and groups of extensions, where each group is a set of extensions sharing at least one feature in common); a firewall management server enforcing the policy via a line sensor; a scanner management server that receives a VA request and, responsively, builds a profile and pushes it to a dialer to perform the VA on the extension and return VA results to the firewall management server; means for detecting a call on an extension to determine call attributes; and means for performing actions based on the VA results per the results response rules. Claim 35 (dependent on 27) confirms the "at least one call attribute" limitation.

Claim 46 — System claim (interface-sensor / CTI-style embodiment).
A system in which the firewall and scanner cooperate around a line/interface sensor: the scanner's prior device-type detection (fax/modem/voice) supplies call-type to the sensor, which evaluates call attributes against the rule base and instructs enforcement; actions based on VA results follow the results response rules. Dependent claims 47–49 add notifying a designated person, logging an event in connection with the call, and updating the security policy.

Claim 50 — Method claim (parallel to claim 16).
A further method of implementing the integrated telephony firewall and scanner system: define the policy; detect a call and its attributes; perform actions per the rules; perform a VA and generate VA results responsive to the VA request; and perform actions based on those results. Dependent claims 51–53: notifying a designated person, logging the event, and updating the security policy.

Claim 54 — System claim emphasizing the line sensor / push-profile path.
A system with a firewall/scanner client defining the Security Policy; a firewall management server coupled to a line sensor; and a scanner management server that pushes a profile including the extension to a dialer for performing the VA and returning VA results to the firewall management server; the system initiates actions based on the VA results. Dependent claims 55–63: notification, logging, policy update, VA-request-driven vs. routinely scheduled profiles, multiple line sensors, multiple dialers, remote placement of sensor/dialer from the client, and TCP/IP connectivity.

Claim 64 — Multi-tier telephony security system (the corporate/regional/branch architecture).
A system spanning multiple customer sites with: a first-tier firewall management server ("FMS") holding a first-tier security policy of call-attribute-based rules; a line sensor at a customer site connected to the first-tier FMS; a second-tier FMS connected to the first-tier FMS holding a second-tier policy; a line sensor connected to the second-tier FMS — wherein each rule of the first-tier policy is designated "required" or "optional," and the second-tier policy must include all the first-tier required rules plus a subset of the first-tier optional rules. Dependent claims 65–69 extend the same required/optional propagation to a third tier, and recite remote placement and TCP/IP interconnection.

Claim 70 — Method of implementing a multi-tier telephony security system.
The method counterpart to claim 64: defining first-tier and second-tier FMS policies with the required/optional designation scheme, enforcing actions via line sensors, with the FMSes remote from one another and connected via TCP/IP (claim 71).

In one sentence: the patent claims, at bottom, (1) a single unified Security Policy shared by a telephony firewall and a vulnerability scanner so that scanner findings automatically rewrite firewall enforcement (via group membership), and (2) a hierarchical, top-down policy-distribution scheme in which upper-tier "required" rules cannot be relaxed — only made more stringent — by lower tiers.

---

4. Litigation / Docket Search Result — Important

I found no CAFC 2026 docket, appeal, or opinion in which US 6,226,372 is the patent in suit. Searches of appellate/docket material returned only unrelated 2026 Federal Circuit activity (e.g., the January 22, 2026 CAFC opinion in the 7,679,637 web-conferencing appeal, W.D. Wash. No. 2:23-cv-00592-JHC, and a 2026 certiorari petition citing that opinion). Neither involves patent 6,226,372.

Two structural reasons this is consistent with expectations, stated as observations rather than conclusions:

• The patent's anticipated expiration is listed as 2018-12-11 (20 years from the 1998-12-11 priority date), with legal status "Expired – Fee Related." An expired patent is a poor candidate for a 2026 infringement appeal.
• What the record does show is defensive/prior-art usage, not assertion:
  • Cited as reference D2 (US 6 226 372 B1, Beebe et al.) in a PCT written opinion (cited in Cisco Exhibit 1002 file histories, PTAB IPR2018-01443, IPR2018-01444, IPR2018-01512 — Cisco Systems v. Centripetal Networks) and in IPR2021-01152 (Palo Alto Networks v. Centripetal Networks).
  • Listed among 169+ "referenced by" citations in later patents (e.g., US 7,882,265; US 8,650,610; US 10,277,633; US 11,233,777), where it appears merely as a cited reference on the face of unrelated patents.
  • Family member US 2001/0014150 A1 shows up in the same citation tables.

If you need a definitive negative, the authoritative checks would be the CAFC docket/opinion search and PACER for any district-court case naming "6,226,372" — my searches did not surface any such 2026 matter, and I will not assert one exists.

---

5. Uncertainty Flags (explicit)

1. Claim 1 full text incomplete. I could not retrieve the complete verbatim body of claim 1 (the recited "means for" elements beyond the security-policy clause). Treat the claim-1 overview above as partially reconstructed.
2. Claim-set anomaly at claims 12–15. The granted claim text as published by FreePatentsOnline renders claim 12 as "The method of claim 1 comprising designating each of the security rules of the second tier security policy as being either required or optional…", and claim 13 as "The method of claim 12…". Claim 1 is a system claim that contains no "first/second tier security policy" antecedent — those terms are first introduced in claims 64 and 70. I am not auto-correcting this. It may be (a) a genuine antecedent-basis/labeling defect in the printed patent, (b) a transcription artifact in the third-party database, or (c) a dependency pointing to the wrong claim number. Only the official USPTO/Google Patents PDF should be treated as authoritative here.
3. Independent-claim inventory. Claims 1, 16, 27, 46, 50, 54, 64 and 70 are confirmed independent by their bodies/dependency references. There is likely one additional independent claim in the 36–45 range (the gap between the claim-27 family, which ends at 35, and the claim-46 family), but I did not retrieve its text and will not assert its number or subject matter.
4. Priority-date discrepancy in secondary sources. The patent face and Google Patents show priority from 09/210,347 filed 1998-12-11; one aggregator page displayed "Priority Date: 1998-12-10." Per your instruction I have not normalized these — the patent's own face (Dec. 11, 1998) is reported as controlling, with the aggregator value noted as a discrepancy.
5. No authoritative confirmation of any 2026 appellate activity. Absence of search results is not proof of absence; it is a null finding.

I'll research litigation involving US Patent 6,226,372. Let me run several targeted searches.

Let me dig deeper with more targeted litigation searches.

Answer: Litigation involving U.S. Patent 6,226,372

Bottom line: Based on the searches I was able to run, I found no litigation in which U.S. Patent 6,226,372 ("Tightly integrated cooperative telecommunications firewall and scanner with distributed capabilities," SecureLogix Corp., issued May 1, 2001) was asserted as a patent-in-suit, and no PTAB proceeding in which it was the challenged patent. I cannot confirm any case number, filing date, or outcome for this specific patent, and I am not going to invent one.

Rather than pad this with matches to other patents in the same family (e.g., US 6,249,575; US 7,440,558), which the search instructions specifically told me not to substitute, here is exactly what the sources did and did not show.

---

What the sources showed

1. The '372 patent appears in litigation/PTAB records only as prior art or a cited reference — never as the patent-in-suit. Every hit tying "6226372" to a case docket was a prosecution file history or a prior-art exhibit used in an IPR about a different patent:

In none of these is the '372 patent the patent being challenged or asserted. These are not litigation involving US 6,226,372 in the sense you asked about, so I am not reporting them as such.

2. The only recent case found naming SecureLogix is one where SecureLogix is the defendant being accused on someone else's patents — not a case involving the '372 patent:

• Data Fence LLC v. SecureLogix Corporation
  • Court: U.S. District Court for the Western District of Texas (Judge Xavier Rodriguez)
  • Case No.: 6:24-cv-00516
  • Filed: October 3, 2024
  • Nature of suit: 35 U.S.C. § 271 patent infringement
  • Status: Answer deadline extended to Jan. 17, 2025 (per the Justia docket retrieved Nov. 25, 2024); one aggregator shows the case as "Closed."
  • Caveat: The patents asserted here are Data Fence's patents, not the '372. This case is therefore not litigation "involving US 6,226,372" as an asserted patent. I list it only because it is the sole litigation hit tied to the '372's assignee that my searches surfaced.

I also saw a reference to SecureLogix Corp. v. TransUnion (No. 5:25-cv-01405, W.D. Tex.), but the complaint analysis indicates that case asserts patents such as US 9,871,913 and US 9,762,728 — not the '372.

3. Commercial footprint of the '372. SecureLogix's own patent-portfolio document (2019) lists US 6,226,372 B1 among patents "protected by" its ETM® System, describing it as covering "cooperative monitoring, vulnerability assessment, and management of telephony resources." This confirms it was a commercially significant patent but tells us nothing about litigation.

---

Why no litigation may appear

• The '372 reached its anticipated expiration on 2018-12-11 (per the Google Patents legal-status record), so the window for it to be asserted is closed.
• The full-text search engines I could reach (Justia dockets, Unified Patents portal, Docket Alarm, FreepatentsOnline, Google Patents) expose '372 primarily as a cited reference; they did not surface a docket with '372 as the asserted patent.

Limitations / what I could not verify

• I could not run an exhaustive PACER or CAFC query. PACER is paywalled and my searches returned no CAFC opinion, Rule 36 judgment, or appeal caption naming the '372 patent.
• It remains possible that an older assertion (circa 2001–2018) exists in a district court or ITC record that is not well indexed in the free databases I reached. If you want certainty, the authoritative check is a PACER "Case Locator / patent docket" search and a CAFC docket search for "6,226,372" (and Southern/Eastern District of Texas and Western District of Texas filings), plus a USPTO PTAB API query for the patent number.

Conclusion: I found no known litigation asserting US 6,226,372. The only '372-adjacent litigation records are cases where it is cited as prior art against unrelated patents, and the only recent case naming its owner (Data Fence v. SecureLogix) concerns other patents entirely. Treat the absence as "not found in the sources searched," not as a positive all-courts confirmation.

I'll verify the ODP default against public sources before reporting.

The ODP block says no AIA proceedings; a Unified Patents portal page surfaced in search, so I need to check whether Unified ever petitioned on this patent.

Let me check PTAB E2E-type listings and SecureLogix's litigation/reexam history for any proceedings on this patent family.

PTAB / AIA Trial Proceedings — US 6,226,372 ("Tightly integrated cooperative telecommunications firewall and scanner with distributed capabilities")

Proceedings overview

Total AIA trial proceedings on file: 0. Breakdown by status: 0 active, 0 claims invalidated, 0 claims sustained, 0 settled, 0 institution denied — because no IPR, PGR, or CBM petition has ever been filed against this patent. The canonical USPTO Open Data Portal structured block reports no AIA proceedings, and targeted web searches (Unified Patents patent portal, FreePatentsOnline, Google Patents, PTAB/family-wide searches) surfaced no petition, institution decision, or FWD naming the '372 patent. The bottom line for a defendant is not "the patent is hardened" — it is that the patent is a dead letter on timing grounds: US 6,226,372 expired 2018‑12‑11, and its "Expired – Fee Related" legal status closes the enforcement window entirely. Anyone whose demand letter cites this patent is asserting a right that generates no post‑expiration liability and, as of 2026, no recoverable back‑damages under the 35 U.S.C. § 286 six‑year lookback.

There are therefore no per-proceeding entries to itemize. The format below is repurposed to document the negative finding and the adjacent evidence I checked, most‑impactful first.

(No proceeding docketed) — No petitioner v. SecureLogix Corporation

• Type: N/A — no Inter Partes Review, Post-Grant Review, or Covered Business Method review ever filed.
• Filed: N/A.
• Status: Not applicable. The '372 is listed on Google Patents as "Expired – Fee Related" with an anticipated expiration of 2018‑12‑11, and the only post‑grant legal‑status entries visible are reassignments/security interests (Silicon Valley Bank security interests 2001‑05‑30 and 2002‑03‑22; releases 2010‑11‑19; a further security interest 2014‑06‑23) and the expiration entry. Sources: Google Patents US6226372B1.
• Judge panel: N/A — no panel ever convened.
• Petition grounds: N/A.
• Institution decision: N/A.
• Final Written Decision: N/A. No claim of the '372 has ever been canceled, confirmed, or construed in any AIA proceeding. Do not accept any representation to the contrary.
• Settlement / termination: N/A.
• Appeal: N/A — no FWD exists to appeal, and I found no Federal Circuit docket or CourtListener entry involving the '372 as a PTAB appeal.
• Defensive value: An IPR-based defense is unnecessary and an invalidity defense may be beside the point, because the stronger argument is term expiry. If you are facing assertion, lead with the 2018‑12‑11 expiration date and the § 286 damages bar rather than spending money at the Board.

Evidence reviewed (negative finding)

• Unified Patents portal page for US-6226372-B1 — contains only a prior‑art/NPL listing (e.g., Sandstorm PhoneSweep, M‑Tech penetration pages, bruck-inc.com pentesting page) and citations to later SecureLogix patents such as US 7,440,558 B2. The presence of this page is not evidence of a Unified Patents petition; Unified maintains database pages for large numbers of patents. I found no Unified Patents‑filed IPR against this patent.
• SecureLogix Patent Portfolio PDF (2019) — SecureLogix's own portfolio summary describes its telephony‑security family (US 6,249,575; 6,320,948; 6,687,353; 6,718,024; 6,760,420; 6,760,421; 7,133,511; 7,440,558; 8,150,013; and foreign counterparts) and does not market the '372 as a standalone asserted asset.
• SecureLogix's later assertion activity targets different patents — e.g., the complaint analysis in SecureLogix Corp. v. TransUnion, No. 5:25‑cv‑01405 (W.D. Tex.) addresses the '532, '913, '728, and '985 patents (Orchestra One / call‑authentication technology), not the '372. See complaint analysis. SecureLogix has also been on the receiving end of a 2024 W.D. Tex. action by Data Fence LLC.
• Reexamination activity in the ecosystem does not touch the '372 — the inter partes/ex parte reexamination controls I encountered (e.g., Control Nos. 95/001,9xx filed 2012‑03‑02, and 95/000,4xx) name unrelated patents (7,415,530; 7,378,992; 7,395,345; 7,321,937; 6,604,158; 6,624,761; 7,161,506). None involves US 6,226,372. I did not verify the ownership of those unrelated patents and make no representation about them.

Why the absence is structural, not accidental

• PGR was never available. PGR applies only to patents subject to first‑inventor‑to‑file, i.e., effective filing dates on or after 2013‑03‑16. The '372 issued 2001‑05‑01 from an application filed 1999‑12‑08.
• CBM was almost certainly unavailable. CBM review (2012‑09‑16 through 2020‑09‑16) excluded "technological inventions." A telecommunications firewall/scanner with a vulnerability‑assessment engine is the paradigm of an excluded technological invention.
• IPR was the only realistic vehicle — and the only plausible window was narrow. IPR has no filing‑date bar, but it is practically driven by co‑pending litigation and the § 315(b) one‑year clock from service of a complaint. The 2007 SecureLogix–Verizon litigation predates IPR availability (2012‑09‑16). By the time IPR practice matured, the '372 was already near or past expiry, extinguishing the incentive to petition.

Strategic summary

Claim status: entirely UNTESTED, and now UNENFORCEABLE. No claim of US 6,226,372 has been canceled (none challenged), none has been confirmed by the Board (nothing was ever instituted), and there is no PTAB claim‑level record to cite. If someone tells you "claims 1‑5 were canceled in IPR" or "the patent survived two IPRs," both statements are false as to this patent — there is no FWD, no certificate, nothing. What is true is that the patent's 20‑year term ran from its earliest effective U.S. filing (1998‑12‑11, the filing date of parent application 09/210,347, to which this CIP claims benefit), producing the anticipated expiration of 2018‑12‑11 recorded on Google Patents. Post‑expiration practice of the claimed subject matter is not infringement, and damages for pre‑expiration conduct are subject to the § 286 six‑year lookback — which, measured from a complaint filed today (2026‑09‑30), reaches back only to 2020‑09‑30, entirely after expiry. Unless there is a tolling suit filed before roughly 2019 that I could not identify, there is no live damages theory.

Estoppel landscape: no estoppel exists. Because no IPR, PGR, or CBM was ever instituted, no § 315(e)(2) or § 325(e)(2) estoppel attaches to any petitioner, real party in interest, or privy. Any defendant's prior‑art and § 112 defenses are procedurally unrestricted. That said, an invalidity defense is largely wasted effort here: the cheap, dispositive answer is expiry plus § 286. Note as a secondary point (unverified against the certified text — verify at USPTO Patent Center before relying on it) that the claim set as reproduced on FreePatentsOnline shows claims 1–11 as "means for…" system claims and then recites claims 12–13 in method form ("The method of claim 1 comprising…," "the second tier security policy") with no antecedent basis in the preceding claims — an apparent § 112 ¶ 2 / indefiniteness defect in claims whose dependencies do not line up with the issued claim set. Treat that as a lead to confirm, not a finding.

Pattern signals. No serial‑petitioner pattern exists because there is no petitioner at all — this is the opposite of the "well‑asserted patents attract IPRs" pattern. There is no defensive aggregator (Unified Patents or otherwise) in the chain. SecureLogix has been an active enforcer of other patents in its portfolio (older telephony‑security family and newer call‑authentication patents), but the '372 is not among the assets it has publicly asserted or kept alive; SecureLogix's own 2019 portfolio document lists a 16‑patent current portfolio that does not include the '372, which is consistent with the patent having been allowed to expire in 2018‑12‑11.

Recommended next steps

1. If you have received a demand citing US 6,226,372, do not file an IPR. Respond with the expiration record: the patent expired 2018‑12‑11 per Google Patents US6226372B1, and there is no maintenance‑fee‑revival or reissue pathway that resurrects past term. Assert that no infringement is possible for post‑expiration conduct and that § 286 bars pre‑expiration damages.
2. Confirm the negative PTAB finding yourself in the authoritative registries before relying on it in a filing: USPTO PTAB E2E / Patent Trial Case Tracking for petition‑by‑patent search, and the USPTO Open Data Portal for the AIA proceedings endpoint. Also confirm the certified claim set at USPTO Patent Center — my claims‑12–13 observation comes from a third‑party reproduction, not the certified copy.
3. If you want a belt‑and‑suspenders invalidity position, be aware that an IPR on an expired patent is technically filable (the Board applies Phillips-style claim construction and the patent owner cannot amend), but it buys nothing when the § 286 window has already closed. Spend the budget on the term‑expiry and damages arguments instead.
4. Watch the real SecureLogix campaign. The company's live enforcement is against its call‑authentication patents (e.g., '532, '913, '728, '985 in SecureLogix v. TransUnion, 5:25‑cv‑01405). If your exposure is to SecureLogix, the '372 is a distraction; the exposure analysis belongs on those newer patents.
5. Caveat on completeness. I did not directly query the PTAB E2E API or CourtListener within this task; the "0 proceedings" conclusion rests on the canonical ODP block plus the web searches described above. My confidence is high, but a defendant filing a formal estoppel or expiry argument should independently re‑run the E2E patent‑number search.

I'll research the assignment record and surrounding corporate/litigation context before writing.

Let me dig for reel/frame details and any NPE-side activity involving this patent family.

US 6226372 B1 — Ownership & Assignment Reconstruction

Data-access disclosure (read first): I could not pull the Assignment Center's per-record pages for this patent in this session. My tooling returned no per-patent assignment record, and the two pages I could retrieve (Google Patents legal events, and third-party mirrors) do not expose reel/frame or correspondent fields. Every reel/frame and correspondent value below is therefore marked not retrieved rather than estimated. The dates and conveyance types are taken verbatim from the Google Patents legal-events table for US6226372B1, which normally mirrors the Assignment Center recordation dates. Do not treat any reel/frame as verified until checked on USPTO Assignment Search (search by patent number) or Assignment Center.

---

Inventors

Pattern notes:

• All five named inventors appear together as assignors on a single recorded assignment to SecureLogix (2000-09-14 event, per Google Patents legal events). No orphaned inventor share — every inventor conveyed, so there is no stray co-owner capable of later decoupling the chain.
• Departed-within-12-months signal: not determinable / no evidence. The assignment record cannot establish departures. The single data point I can confirm (Collier still CTO roughly 25 years later) argues against a founder exodus.
• The company was founded in 1998 by Richard H. Jordan and Lee Sutterfield, both from WheelGroup (acquired by Cisco). Note that neither founder is a named inventor here — inventors and founders are distinct populations at SecureLogix.
• Priority chain: this patent is a continuation-in-part of Ser. No. 09/210,347 (filed 1998-12-11), which is the source of the 1998-12-11 priority date and is itself the parent of the SecureLogix family.

---

Original assignee

SecureLogix Corporation (San Antonio, TX) — named original assignee on the face of the patent and listed as current assignee in Google Patents.

• Primary line of business: enterprise telephony/voice security. Its flagship is the ETM® System (voice firewall + intrusion prevention), preceded by the 1999 launch of TeleSweep Secure 1.0 ($17,999, per contemporaneous trade press) and TeleWall, the telecom firewall. The commercial product line maps directly onto this patent's subject matter, and SecureLogix's own 2019 portfolio document groups the family under "Integrated telephony resource vulnerability assessment and management" and states the patents protect technology in the ETM System.
• Did they ship a product embodying the claims? Yes — the ETM System is the commercial embodiment, and the company states its products secure ~3.5 million enterprise phone lines.
• Current status: operating, privately held, ~71 employees, VC-backed (Series A 2000, Series B 2002, Series C 2003, 2020 PPP, 2021 secondary). Investors include Gen Digital. No bankruptcy, dissolution, or acquisition found.
• Caveat worth flagging: US 6,226,372 is not enumerated in SecureLogix's own June 2019 "SecureLogix Patent Portfolio" PDF (which lists 13 U.S./international patents plus 2 TeleVPN patents). That is consistent with the patent having already reached the end of its enforceable life around 2018 (see below), not with a transfer out.

---

Assignment timeline

Six recorded conveyances are attributable to this patent. Execution dates and reel/frame numbers were not retrievable from my sources — the rows below carry the recordation-style dates shown in Google Patents legal events. This is a recordation-date timeline, not an execution-date timeline.

• Executed: not retrieved / recorded 2000-09-14 — Reel not retrieved

  • Conveyance: Assignment of Assignors' Interest (inventor → company)
  • Assignor: Todd Beebe, Mark D. Collier, Doug Conyers, Stephen Faustino, Chris Hamlett (all five)
  • Assignee: SECURELOGIX CORPORATION
  • Correspondent: not retrieved — cannot be scored for recurrence
  • Context: Initial employment/invention assignment perfecting company ownership; this is the link that makes SecureLogix the record owner.

• Executed: not retrieved / recorded 2001-05-30 — Reel not retrieved

  • Conveyance: Security Interest (see document for details) — i.e., an IP security agreement, not an ownership transfer
  • Assignor: SecureLogix Corporation
  • Assignee: SILICON VALLEY BANK
  • Correspondent: not retrieved
  • Context: Securitization — collateral grant under a venture-debt facility; residual title stays with SecureLogix.

• Executed: not retrieved / recorded 2002-03-22 — Reel not retrieved

  • Conveyance: Security Interest
  • Assignor: SecureLogix Corporation
  • Assignee: SILICON VALLEY BANK
  • Correspondent: not retrieved
  • Context: Securitization — a second, separate collateral grant (consistent with the Series B financing period).

• Executed: not retrieved / recorded 2010-11-19 — Reel not retrieved

  • Conveyance: Release
  • Assignor: SILICON VALLEY BANK
  • Assignee: SECURELOGIX CORPORATION
  • Correspondent: not retrieved
  • Context: Lien release — SVB discharges a security interest; SecureLogix unencumbered as to that lien.

• Executed: not retrieved / recorded 2010-11-19 — Reel not retrieved (second, separate release entry, same date)

  • Conveyance: Release
  • Assignor: SILICON VALLEY BANK
  • Assignee: SECURELOGIX CORPORATION
  • Correspondent: not retrieved
  • Context: Lien release — discharges the second of the two pre-2010 security interests (i.e., one release per 2001 and 2002 grant; the source does not map each release to its originating lien).

• Executed: not retrieved / recorded 2014-06-23 — Reel not retrieved

  • Conveyance: Security Interest
  • Assignor: SecureLogix Corporation
  • Assignee: SILICON VALLEY BANK
  • Correspondent: not retrieved
  • Context: Securitization — a third collateral grant, apparently under a later credit facility. No corresponding release appears in the legal-events record, and none appears for any later date. Flag as an open/likely-moot encumbrance (the patent expired in 2018, and SVB itself failed into FDIC receivership in March 2023 — general knowledge, verify — so any surviving lien would sit with a successor institution and be practically unenforceable against an expired patent).

Non-assignment legal events (excluded from the chain): application filed 1999-12-08; priority claimed from US 09/210,347 (1998-12-11); PCT/US2000/033089 and AU 19503/01 priority events (2000-12-06); continuation priority to US 09/761,343 (2001-01-16); grant 2001-05-01; anticipated expiration 2018-12-11. Legal status per source: Expired – Fee Related.

Bottom line on this section: there is no ownership transfer away from SecureLogix anywhere in the record. The only non-inventor assignee in the entire chain is Silicon Valley Bank, and only as a secured lender, three times, with two releases.

---

Timeline diagram

timeline
    title Ownership of US 6226372
    1999 : Filed by SecureLogix Corp
    2000 : Inventors assign to SecureLogix Corp
    2001 : Patent issues May 1
         : SVB records security interest
    2002 : SVB records second security interest
    2010 : SVB releases both security interests
    2014 : SVB records third security interest
    2018 : Patent reaches end of term

---

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT. No "IP / Patents / Licensing / Holdings / Ventures" entity appears anywhere in the record. The assignees are SecureLogix Corporation (operating) and Silicon Valley Bank (lender). No single-purpose LLC, no registered-agent-service address, and no change of name filing appears in the legal-events table for this patent.

2. Known asserter in the chain — NOT PRESENT. I checked the chain against the listed directories: Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, Spangenberg entities. None appears. Note the inverse traffic: Data Fence LLC v. SecureLogix Corp., No. 6:24-cv-00516 (W.D. Tex., filed 2024-10-03), with Isaac Rabicoff of record for the plaintiff — that is an NPE suing our patent owner on unrelated patents (US 8,917,843 / 9,491,286 / 9,819,797), not a transfer of US 6,226,372 to an NPE.

3. Repeat correspondent across the chain — NOT VERIFIABLE (unclear). Correspondent-of-record data was not retrievable for any of the six entries. I will not name an attorney. This is the single most important gap in this reconstruction: the two SVB releases (2010-11-19) and the three SVB security interests (2001-05-30, 2002-03-22, 2014-06-23) would normally share a bank-side recording attorney, and confirming whether they do would either close or open this signal. Recommend direct pull of reels on Assignment Center before relying on this section.

4. Cascading transfers — NOT PRESENT. There is no run of chained LLC-to-LLC assignments. The only repeat assignee is SVB across a 13-year secured-lending relationship (2001 → 2014), which is the opposite of a rapid-fire cascading pattern, and which was twice unwound by recorded releases.

5. Pre-litigation transfer — NOT PRESENT. No assignment precedes any suit naming US 6,226,372; I found no infringement action asserting this patent at all, by SecureLogix or anyone else. SecureLogix's live assertion (SecureLogix Corp. v. TransUnion, No. 5:25-cv-01405, W.D. Tex., filed 2025-10-31, targeting the TRUSTID competitor) pleads later call-authentication patents (e.g., US 9,871,913; 9,762,728; and a '985 patent) — not the '372.

6. Bankruptcy fire-sale — NOT PRESENT. No Chapter 7/11 of SecureLogix appears in the record or in the financing history (Series A/B/C, 2020 PPP, 2021 secondary — all going-concern events). SecureLogix remains an operating concern in San Antonio.

7. Privateering — NOT PRESENT. There is no operating-company-to-NPE transfer anywhere in the chain, so there is nothing to support this signal.

8. Defensive aggregator — NOT PRESENT. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. (A Unified Patents portal page exists for US-6226372-B1, but that is a patent-reference page, not evidence of ownership — I explicitly do not count it as a defensive-aggregation event.)

Aggregate read: of the eight signals, six are affirmatively absent (1, 2, 4, 5, 6, 7, 8), one is unverifiable (3), and none is present. There is no NPE link in this chain to score.

---

Verdict

Operating-company assertion.

The complete recorded chain is inventors → SecureLogix Corporation (recorded 2000-09-14), with only Silicon Valley Bank ever appearing as a non-inventor assignee — three times as a secured lender (recorded 2001-05-30, 2002-03-22, 2014-06-23) and twice as releasor in favor of SecureLogix (both 2010-11-19). Ownership never left the operating company, so none of the shell-LLC, cascading-transfer, privateering, or defensive-aggregator signals can be satisfied; the "repeat" party in this chain is a bank enforcing and releasing collateral, which is a financing artifact, not an assertion play.

Two honest qualifications: (a) this specific patent was apparently never asserted — it reached end of life on 2018-12-11 with status "Expired – Fee Related," and SecureLogix's current assertion against TransUnion rests on younger sibling patents; and (b) the 2014-06-23 SVB security interest shows no recorded release, a loose end that is almost certainly moot on an expired patent but should be closed out on the source reels.

Verification links

• USPTO Assignment Search (search by patent number): https://assignment.uspto.gov/patent/index.html
• USPTO Assignment Center: https://assignmentcenter.uspto.gov/
• Google Patents legal events (dates and conveyance types used above): https://patents.google.com/patent/US6226372/en

Open items requiring the reel-level pull

1. Reel/frame and execution dates for all six conveyances (source used shows recordation-style dates only).
2. Correspondent of record for each entry — the one field that decides Signal 3.
3. Whether a release exists for the 2014-06-23 SVB security interest, outside the legal-events feed.

I'll research the cited prior art for US 6,226,372. Let me run targeted searches on the patent's front-page "References Cited" and related prosecution records.

The searches so far returned references that cite '372 ("Cited By"), not the prior art cited in '372. Let me pull the patent's own front-page "References Cited" list.

I need the actual "References Cited" on the face of '372 — the searches are returning patents that cite '372, not the prior art '372 cites. Let me pull the Justia and Google Patents citation tables directly.

I hit the tool-call limit before I could retrieve the full Google Patents/Justia citation tables verbatim, so let me be explicit about what I actually obtained versus what remains unverified, and give you the prior-art analysis on that footing.

---

Prior Art Analysis — US 6,226,372 B1

0. Scope, confirmation of the number, and a sourcing caveat

Number confirmed literally: US 6,226,372 B1 ("Tightly integrated cooperative telecommunications firewall and scanner with distributed capabilities"), application 09/457,494, SecureLogix Corporation, filed 1999-12-08, granted 2001-05-01, priority claimed from 09/210,347 filed 1998-12-11. No similar-numbered patent was substituted. Sources retrieved: Google Patents (patents.google.com/patent/US6226372B1/en), Justia Patents (patents.justia.com), the Unified Patents patent record (portal.unifiedpatents.com/patents/patent/US-6226372-B1), and Docket Alarm PTAB exhibits (IPR2018-01512 / IPR2021-01152).

Caveat you must weigh (important): I was not able to pull the patent's verbatim front-page (56) References Cited field or the Google Patents "Patent Citations" table for '372 within my search budget. What I did retrieve is the Unified Patents "Prior Art" listing for US-6226372-B1, which aggregates the cited prior art for that exact patent. Every entry in that list pre-dates '372's 1998-12-11 priority date, and the subject matter is thematically congruent with '372 (telephony fraud, PBX modem blocking, network firewalls, line testing). That is strong, but circumstantial, evidence that this is the (56) list. Treat the table below as a well-grounded reconstruction, not a verbatim read of the printed patent. The authoritative check is column (56) of the USPTO/Google Patents PDF, or the PatentCenter file wrapper for 09/457,494.

I am also not asserting actual anticipation for any reference. I have not read these documents. §102 anticipation requires a single reference disclosing every limitation as arranged in the claim; what follows is a potential-relevance map with a strength rating, not a legal conclusion.

---

1. Legal framework that governs the mapping

'372 is a pre-AIA patent (filed 1999-12-08), so §102(a)/(b)/(e)/(g) and §103 apply, and the effective date differs claim-by-claim because this is a continuation-in-part of 09/210,347 (filed 1998-12-11):

• Claims fully supported by the 09/210,347 disclosure → effective date 1998-12-11; §102(b) critical date 1997-12-11.
• Claims reciting CIP-added matter (notably the multi-tier "required vs. optional rule" architecture of claims 64–71, and much of the scanner/dialer/profile subject matter) → effective date 1999-12-08; §102(b) critical date 1998-12-08.

Consequence: every reference below is prior art under §102(a) or (b) against all claims, because all of them issued or were filed well before December 1997. The interesting question is not whether they are prior art but how much of '372's specific combination they reach.

Also note: a (56)-cited reference is one the examiner already considered — '372 issued over all of them. That cuts against the theory that any of them individually anticipate the granted claims, and pushes the realistic challenge toward §103 combinations.

---

2. Cited prior art — reference-by-reference

Dates are the dates as listed in the Unified Patents record (they correspond to filing/priority dates, not issue dates). "§102 strength" is my assessment of standalone §102 viability; "§103 value" is how useful the reference is in combination.

(Row numbering above preserves the retrieved list; rows 8, 11, 16, 20, 22, 30 are items I could not fully characterize because the retrieved snippet truncated titles. I am flagging these rather than guessing.)

---

3. Most relevant prior art — ranked

If forced to name the references with the highest potential materiality to '372's claims:

1. US 5,018,190 A — "Device to Block Unauthorized Modem Access Over a PBX Line." This is the single closest telephony-specific reference in the cited set. It speaks directly to '372's core "unauthorized modem on a PBX line" problem and the deny-on-modem enforcement of claims 1 and 2–11 and the PBX-based embodiments (claims 46, 54). Standalone §102 viability is nonetheless limited because it lacks the integrated scanner + shared Security Policy + results-response architecture.
2. US 5,826,014 A and US 5,623,601 A (network firewalls) — best §103 base references for the "security policy / rule base / chokepoint enforcement" backbone of claims 1, 16, 27, 50, 54. Neither teaches telephony extensions, a PSTN scanner, or a dialer.
3. US 6,154,775 A (dynamic firewall rule processing) — the best §103 candidate against the auto-adjustment limitations (claims 4, 11, 32–34, 51–53, 57) because it expressly contemplates dynamically altering rule operations.
4. US 5,812,763 A (expert-system security inspectors) and US 5,555,742 A (intrusion detection) — the §103 references for the automated vulnerability-assessment / "inspect for a security flaw and respond" concept, though both are computer-system, not telephony.
5. US 5,276,529 A and US 5,854,889 A (remote line testing / protocol analysis; heterogeneous telecom testing) — §103 references for the scanner/Dialer half of '372 (auto-dialing a line, detecting and analyzing what answers).

Notably absent: I found no cited reference directed to the multi-tier "required vs. optional rule" propagation of claims 64–71, and none combining a telephony firewall and a vulnerability scanner through a shared, synchronously updated Security Policy. Those appear to be the genuine points of novelty that let '372 issue. A §103 challenge to claims 64–71 would need art outside this cited set (e.g., hierarchical policy-distribution/SNMP management references — several of which appear in later patents' citation tables, such as US 5,819,028, US 6,018,100, US 6,108,782, US 6,212,558 and US 6,243,815, but those post-date or are contemporaneous and are not on '372's face).

---

4. References that are frequently confused with '372's prior art (but are not)

Do not treat these as §102 art against '372:

• "Cited By" / forward citations (e.g., US 7,882,265; US 8,650,610; US 9,118,709; US 10,277,633; US 11,233,777; US 2003/0061346 A1's citation table). All post-date '372 and merely cite it.
• The TDM/encryption cluster that appears in some aggregator snippets (US 4,866,773; US 5,003,599; US 5,084,891; US 5,161,191; US 5,970,095; US 6,098,172) surfaced in my search as the "Patent Citations" list of a different patent page (US20050025302A1, "Virtual private switched telecommunications network") that cites '372 — I verified this by URL and by subject-matter fit (those references are TDM-encryption art, not telephony-security art). I am not attributing them to '372's (56) field. Only US 6,098,172 coincidentally also appears in the '372-associated list.
• Foreign/family documents (WO 01/043343 A1; AU 19503/01 A; US 2001/0014150 A1 from 09/761,343; JP 4,690,480 B2) are later, family members, not prior art.

---

5. Reverse-direction signal: what third parties found material in '372

This is genuinely informative about which parts of '372 are the strongest disclosure, and it comes from records I did retrieve:

• In the EPO/ISA search report reproduced in the file histories used as Exhibit 1002 in both IPR2018-01512 (Cisco v. Centripetal) and IPR2021-01152 (Palo Alto Networks v. Centripetal), '372 is cited as an "X" (most relevant) document: "US 6 226 372 B1 (BEEBE TODD [US] ET AL) 1 May 2001 … column 3, line 38 – column 4, line 32; claims 1–11 — relevant to claims 1–20." That is a third-party admission that claims 1–11 and the disclosure at col. 3:38–4:32 are the material part of '372 — consistent with my ranking above that the firewall/scanner policy-and-rule architecture (claims 1–11) carries the weight.
• '372 was also cited as reference "D2" in a PCT written opinion (per the Cisco Exhibit 1002 file histories). Again: cited against others, never asserted as a patent-in-suit — consistent with the litigation summary already generated.

---

6. Related-application prior art (same applicant) — §102(e)/§102(g) dimension

'372 expressly incorporates by reference:

• US application 09/210,347 (filed 1998-12-11) → issued as US 6,249,575 B1, "Telephony security system" — the firewall parent.
• US application 09/312,365 (filed 1999-05-14), "A Distributed System and Method for System Identification and Vulnerability Scanning" — the scanner parent.

Both are the applicant's own work, but as a matter of §102(e)/§102(g) mechanics they are the substantive disclosures that support claims 1–35 (firewall) and the scanner claims, and they define the effective-date split described in §1 above. Any invalidity theory for the CIP-only claims (64–71) that relies on the 1999 date must reckon with the fact that the core firewall/scanner combination is entitled to the 1998-12-11 date.

---

7. Bottom line

• Most relevant cited prior art: the telephony-specific US 5,018,190 (block unauthorized modem access over a PBX line) and, especially for §103, the firewall pair US 5,826,014 / US 5,623,601, plus US 6,154,775 (dynamic rule alteration), US 5,812,763 (security flaw inspection) and US 5,555,742 (intrusion detection).
• Claims most at risk under a single-reference §102 theory (my assessment): essentially none of the cited references anticipates the integrated firewall+scanner+shared-policy claims (1, 16, 27, 50, 54) standing alone; the realistic exposure is §103 for the rule-base/enforcement claims and the auto-policy-update dependent claims (2–11, 32–34, 51–53).
• Claims least at risk: 64–71 (multi-tier required/optional policy propagation) — no cited reference addresses it.

---

8. Uncertainty flags (explicit)

1. Source of the citation list. The table in §2 comes from the Unified Patents record for US-6226372-B1, not from a verbatim read of the patent's printed (56) field. I could not retrieve Google Patents' or Justia's citation table within my search budget. Verify against the patent PDF / PatentCenter file wrapper before relying on it.
2. Dates. The dates shown appear to be filing/priority dates, not issue dates. I have not converted them.
3. Truncated entries. Six items in the retrieved list (notably the 5,510,777; 5,535,265; 5,276,731; and three firewall-family items) had no title returned; I have flagged them rather than supplied a guess.
4. No anticipation opinion. I have not read any of these references. The §102 column is a hypothesis map keyed to the claim families established in the earlier summary, not a legal conclusion; §102 requires element-by-element disclosure in a single reference.
5. The (56) list may be longer. The patent face typically carries more references than the ~28 I was able to enumerate; additional foreign patent documents and non-patent literature may exist and are not covered here.

I'll analyze obviousness under § 103, but I need to ground the prior-art combinations in actual references rather than assert them from memory. Let me search for the prior art cited on the face of this patent and the relevant field references.

I have strong grounding. Let me pull the complete "References Cited" list from the patent face and check the key secondary references (the products/papers cited as prior art).

Let me verify the key secondary references so I can describe them accurately rather than from memory.

Obviousness Analysis — US 6,226,372 B1 under 35 U.S.C. § 103

Scoping note. I am treating the "Prior Art section of this page" as (a) the References Cited list printed on the face of US 6,226,372 B1 (retrieved via FreePatentsOnline and the Google Patents PDF), and (b) the prior-art role the patent played in the PTAB matters identified in the earlier Litigation section. I am not substituting any similar-numbered patent. Where I could not verify a reference's content or date directly, I say so rather than assert it.

Two threshold flags before the analysis:

• The patent is expired. Legal status "Expired – Fee Related," anticipated expiration 2018-12-11. This is a retrospective validity analysis, not a live-controversy one. Nothing here should be read as an assertion of unenforceability, and the earlier sections' null finding on 2026 CAFC activity is unaffected.
• Contradiction flag (carried forward): the earlier Patent summary flagged that claims 12–15 as printed recite "the method of claim 1 … second tier security policy," although claim 1 is a system claim with no tier antecedent. That anomaly matters here: it determines whether the multi-tier "required/optional" subject matter is claimed at 12–15 and 64–71, or only at 64–71. I analyze it both ways below and do not auto-correct the numbering.

---

1. The § 103 framework and the priority-date gate

PHOSITA. A person having ordinary skill in the art at the relevant time — a bachelor's degree in electrical engineering or computer science plus approximately 3–5 years in telecommunications or network security — who is familiar with: PBX and central-office trunk signaling (ANI/Caller ID, DTMF/MF, CAS); PBX call-accounting output (Station Message Detail Recording SMDR / Call Detail Recording CDR); commercial war-dialers; TCP/IP firewalls and their rule engines; SNMP notification; and CTI interfaces.

Critical gate — the '372 is a continuation-in-part. It claims priority to US application 09/210,347 (filed 1998-12-11, issued as US 6,249,575 B1, "Telephony Security System"). Subject matter actually supported by that parent gets the 1998-12-11 date. Subject matter new in the CIP — most importantly the cooperative firewall-plus-scanner limitations and the multi-tier limitations — is entitled only to the CIP filing date of 1999-12-08. That distinction is decisive for at least one reference below.

Common-ownership exclusion. US 6,249,575 B1 and US application 09/312,365 (the distributed scanner application, filed 1999-05-14, incorporated by reference) are commonly owned by SecureLogix. As they can only qualify as prior art under § 102(e), pre-AIA § 103(c)(1) removes them from the § 103 combination. I therefore do not use the '575 or 09/312,365 as § 103 references, even though their disclosures overlap heavily with the '372. This is a significant narrowing of the attack surface, and it is exactly why the analysis below leans on the foreign publications and non-patent literature on the '372 face.

What survives as usable art (all § 102(a)/(b) publications, not § 102(e)):

Uncertainty flag: the last four rows come from the Unified Patents citation cluster for US-6226372-B1, which mixes "cited by / similar documents." I could not confirm each is literally printed on the '372 face. Treat them as corroborating context, not as established of-record art. The rows from WO 1998053635 and WO 1998017072 are confirmed on the face.

---

2. Independent claims at a glance

Plus a probable independent claim in the 36–45 gap (flagged as unverified in the prior summary — I do not assert its content).

---

3. Combination A — the core integrated firewall/scanner claims (1–26, 50–53, and by extension much of 27–63)

Proposed combination:

• Primary — a telephony access-control/monitoring reference. WO 1998053635 A2 (Deutsche Telekom, "Device for monitoring a connection setup") alone or in view of US 5,018,190 (Walker — blocking unauthorized modem access over a PBX line) and US 4,332,982 (Thomas — toll call security and logging), each teaching a line-side device that inspects a call's attributes and permits/denies/logs according to a rule set.
• Secondary — a telecommunications scanner reference. The Sandstorm PhoneSweep commercial war-dialer (cited on the '372 face) together with the penetration-testing resources also cited on the face (tlogic.com/penetration.html, m-tech.ab.ca/security/penetration, bruck-inc.com … pentesting), which collectively teach dialing a range of extensions, detecting whether a device is a modem/fax/voice, identifying the software controlling the modem by signature/banner analysis, and attempting penetration using default credentials — then reporting results.
• Tertiary — an automated-response/rule-dynamics reference. US 6,154,775 (firewall with dynamic rule processing and ability to dynamically alter rule operations) and US 5,627,886 (real-time monitoring that triggers automated responses), supplying the "results drive policy change / notification" element.

Why the PHOSITA would combine them — the four KSR rationales are unusually clean here:

1. The patent's own background concedes the gap and the need. The specification states that scanners "only report their findings and cannot enforce a security policy to deny access to or segregate unknown or penetrable modems," and that firewalls "are reactive tools … incapable of both proactively looking for unknown modems, and proactively evaluating the vulnerability of known modems." Stating the deficiency and the desired capability is itself a strong motivation-to-combine datum; the inventor is identifying two known tools with complementary, non-overlapping shortcomings.

2. The NISSC 1999 paper supplies the explicit blueprint. "A Common Weak-Link in the Security Chain" (NISSC 1999, on the record as csrc.nist.gov) expressly analogizes to the TCP/IP world — "scanners, firewalls, and intrusion detection systems" — and states that what is needed is "a coordinated approach … systems designed to control and manage the use of modems and the telephone lines themselves," including distributed dialing consolidated at a central site. If this paper is prior art (it post-dates the 1998 parent but pre-dates the 1999 CIP filing — see §1), it is close to a one-reference motivation for Combination A. Caveat: it discusses SecureLogix's own Telesweep Secure and TeleWall products, so its precise prior-art status and authorship should be verified before reliance.

3. Combination of known elements per known methods (KSR factor 2). Both the firewall rule engine (attribute → action, sequential rule base, logging/notification) and the scanner engine (dial → detect → identify → penetrate → report) were known, mature, and used the same underlying telephony primitives (DTMF/MF, Caller ID/ANI, handshake analysis). Feeding the scanner's output into the firewall's rule engine as just another input — and letting a rule in the firewall's rule base invoke the scanner — is the straightforward application of a known technique (event-driven rule invocation) to a known environment.

4. The "move the extension between groups" mechanism (claims 2–3, and the Results Response Policy). Grouping resource identifiers into named sets and reassigning them to alter policy treatment is standard access-control practice (roles/groups in operating systems and network firewalls). Once the firewall is group-based, having a VA result trigger a group reassignment is a predictable variation of the known "adjust policy" action — the '372 itself describes it as "moving the extension … into a different Group, thereby changing the manner in which future calls on that extension will be handled."

Likely-strength assessment: Claims 1, 16, 50 and their dependents reciting allow/deny/permit, detect call attributes, VA by penetration attempt, notification, and logging are the most exposed. The single most defensible limitation across the independent claims is the requirement that the same Security Policy is used by both the firewall and the scanner components during both their cooperative and independent operations (claim 1; mirrored in the abstract and specification). A challenger must show the art teaches one shared policy object rather than two products merely talking to each other. That is the crux and the answer should be built around it.

---

4. Combination B — distributed client/server claims (27–45, 54–63)

Add to Combination A:

• US 5,623,601 (Vu — secure gateway between networks) and US 5,898,830 / US 5,826,014 for the client/server firewall-management architecture.
• US 5,276,529 (Williams — remote testing and protocol analysis of communication lines) for the remote line-sensor/dialer placement and central management.
• WO 1998017072 A1 ("Dialing device") for the programmable, line-powered dialer element — with a caveat: my retrieval shows this reference is directed to reprogramming a subscriber dialer over the telephone line (dialing mode / sleep mode; DTMF and pulse signaling), not to vulnerability scanning. Do not overstate it. It supports "a dialer that is remotely provisioned," not "a scanning dialer."

Motivation. Enterprise call-accounting and PBX management were already centrally administered; the '372's own description of the problem — that "a single computer handling all processing of a globally distributed enterprise would be quickly overloaded" and that "a firewall and scanner management server is most often installed at each location" — is a recitation of the routine design tradeoff between centralized and distributed processing (KSR factor 3: design incentives and market forces). Distributing sensors/dialers and controlling them over TCP/IP was conventional.

Weakest point for the challenger: claims 54–63's specific "SMS pushes a profile including the extension to a dialer" and the round-robin over multiple concurrent profiles recited in the specification. If a reference cannot be shown to push a per-extension profile to a dialer, dependent claims in this family may survive individually even if the independent claim falls.

---

5. Combination C — CTI/interface-sensor claims (46–49)

Add to Combination A: standard PBX computer-telephony-integration art. The '372's claim 46 embodiment is essentially: the PBX supplies call attributes via CTI, and the sensor evaluates a rule base and instructs the PBX to enforce. Using a PBX to supply attributes and to execute call control is the definition of CTI, and CTI interfaces (TAPI/TSAPI and proprietary equivalents) long predate 1998.

Motivation. The '372 itself frames this as the same system "complemented with computer telephony integration (CTI) interfaces to specific PBXs," and the only novel-seeming element — using the scanner's prior device-type detection to supply the missing call-type to the sensor — is again the Combination-A integration idea applied to a CTI platform. Strong § 103 candidate.

Note: dependent claims 47–49 (notify a designated person / log the event / update the policy) are individually the weakest claims in the patent on obviousness grounds; notification and logging are on the face of US 4,332,982 and US 5,627,886.

---

6. Combination D — the SMDR/CDR correlation dependent claims

Proposed combination: US 4,332,982 (Thomas — toll call security and logging) in view of ordinary PBX SMDR/CDR call-accounting practice (PBX vendors' SMDR output was ubiquitous by 1998), optionally with US 5,276,529 (Williams — remote testing/protocol analysis of communication lines).

Motivation. The '372 states the problem itself: "For outbound calls, it is common for PBXs to mask the actual originating number/extension, and send no number or a default number instead." The claimed remedy — buffer the under-specified call record, obtain the PBX's own SMDR record, and correlate the two on time/trunk/channel — is the textbook use of call-accounting data to fill a monitoring gap, and the weighting of "start time, source or destination number, trunk group, trunk, and channel ID" is the field's standard join-key set. This is a predictable, known-technique combination.

Weakest point: the specific weighted scoring and the buffering/ambiguity-timeout behavior are implementation details that, if claimed with precision, may not be squarely disclosed — a challenger would want a secondary reference on data-record correlation.

---

7. Combination E — the multi-tier "required vs. optional" claims (64–71, and 12–15 if those depend from 64/70)

Add to Combination A/B: hierarchical, top-down policy distribution and filtering art: SNMP-based enterprise network management hierarchies, directory-based policy push (e.g., a central server distributing rules to subordinate agents that may not relax them), and US 5,898,830 / US 5,826,014 for the firewall-rule-management layer.

Motivation. Centralized definition with constrained local override, upward event routing, and filtering of notifications at each tier is the standard model for enterprise network management and for regulatory/compliance-style policy trees. KSR factor 2 (known elements combined per known methods) applies squarely: the only distinctive feature is the "required/optional" classification with a no-more-lax-than-parent constraint, which is the ordinary consequence of a hierarchy in which a parent dictates a floor.

Reality check on this family: I regard claims 64–71 as the most vulnerable family in the patent, because (i) the required/optional distinction is a drafting choice, not a technical advance, and (ii) the filtering/upward-routing behavior is generic SNMP-trap-management practice. If the claim-12 anomaly is real and claims 12–15 depend from claim 1 rather than 64/70, those claims additionally fail for lack of antecedent basis (§ 112) independent of § 103 — worth flagging to whoever uses this analysis, but I am not resolving the anomaly, per the earlier instruction.

---

8. Consolidated motivation-to-combine table (KSR factors)

---

9. Where the patent likely survives, and secondary considerations

• The "single shared Security Policy" limitation (claim 1; and the "synchronously adjusted … in both the firewall and the scanner components" requirement) is the limitation most likely to defeat a § 103 challenge built on separate scanner and firewall products. A challenger needs art that unifies the policy object across both engines.
• "Automatic synchronous adjustment … in response to the vulnerability assessment results" combining proactive scheduled scanning + firewall-initiated VA requests + a shared results-response policy is the genuine inventive kernel; if any of the Combinations above fails, it will be because the secondary reference stops at "report" rather than "rewrite the enforcement policy."
• Objective indicia the record supports: SecureLogix's own portfolio document (2019) identifies US 6,226,372 B1 as covering "cooperative monitoring, vulnerability assessment, and management of telephony resources" implemented in the commercial ETM® System — evidence of commercial success and industry recognition. The patent's family (WO 2001043343 A1; AU 19503/01 A; JP 4690480 B2; US 2001/0014150 A1) shows international pursuit. Note, however, that no nexus has been established here between the commercial product and the specific claimed subject matter, and commercial success evidence is weak where the product embodies many patents.
• Prosecution reality: the '372 issued over the very references cited on its face. That is not a legal shield, but it is strong circumstantial evidence that the Examiner (Fan Tsang) did not find the combinations above to be plainly present in those references — most plausibly because none of them taught the shared-policy/unified-engine concept.

---

10. Explicit uncertainty flags

1. The "Prior Art section" is ambiguous. I have used the face-of-patent References Cited list plus the PTAB citation context from the earlier Litigation section. I did not have a discrete "Prior Art" tab; if one exists with different content, this analysis should be re-run against it.
2. Reference content unverified: US 5,892,903, US 5,805,803, US 5,898,830, US 5,826,014, US 6,098,172 and US 6,154,775 appear in the Unified Patents citation cluster but I could not confirm they are printed on the '372 face. Their titles/dates are as the source displayed them; I have not independently verified them.
3. WO 1998017072 A1 characterization: on the retrieved text it is a remote-programmable dialer, not a scanning dialer. Do not cite it as a scanner reference.
4. NISSC 1999 date: October 1999 — after the 1998-12-11 parent priority but before the 1999-12-08 CIP filing. Its status depends entirely on which claims are entitled to which date; and it discusses the patentee's own products, raising authorship/§ 102(b) questions I cannot resolve here.
5. Claim 12–15 numbering anomaly is unresolved and materially affects the multi-tier analysis.
6. No claim chart was built against full verbatim claim text for claims 1 and 36–45 (the latter not retrieved at all). Conclusions about those claims are inferential.
7. Common-ownership exclusion is my legal judgment based on the assignment records shown (both patents assigned to SecureLogix). If a challenger can show the '575 or 09/312,365 subject matter was "developed by another person" outside common ownership at the time, the exclusion would not apply and the analysis changes significantly — that would be the highest-value thing to check.

Bottom line: the strongest § 103 case is Combination A (Deutsche Telekom WO 1998053635 + Walker/Thomas + a 1998 commercial war-dialer such as PhoneSweep + a dynamic-rule firewall reference), aimed at the core independent claims (1, 16, 50) and the CTI claims (46–49), with the NISSC 1999 paper supplying motivation if its date holds. The multi-tier family (64–71) is the most vulnerable to a generic hierarchical-policy-distribution combination. The hardest limitation for any challenger remains the single, shared Security Policy synchronously governing both the firewall and the scanner — that is where the patent's validity, if it has any, lives.