US 6944183B1

I'll run targeted searches for this patent number and its litigation history.

Let me pull the actual claim language and check for any 2026 litigation.

Let me locate the actual claims and identify the 2014 Delaware litigation parties.

US 6,944,183 B1 — Verified Bibliographic Data

I ran targeted searches against Google Patents, FreePatentsOnline, Justia, Patsnap, and litigation/PTAB/Federal Circuit material. Everything below is grounded in the sources retrieved; where I could not verify something, I say so explicitly.

Source: https://patents.google.com/patent/US6944183/en ; https://FreePatentsOnline.com/[6944183](/patent/6944183).html ; https://eureka-patsnap-com.sutd.idm.oclc.org/patent-[US6944183B1](/patent/US6944183B1)

Family / related matter (from the patent's own cross-reference section): provisionals 60/138,849, 60/138,850, 60/139,033–60/139,036, 60/139,038, 60/139,042–60/139,044, 60/139,047–60/139,049, 60/139,052, 60/139,053 (all filed June 10, 1999) and 60/139,076 (June 11, 1999); siblings 09/591,802, 09/592,079, 09/592,163, 09/592,165, 09/592,442, 09/592,443, 09/591,801 (now US 6,708,187) and 09/592,083 (now US 6,678,835). A PCT counterpart, WO 00/78004 A2 (Alcatel Internetworking Inc., 21 Dec 2000), was cited as prior art in WO2016049376A1.

---

Abstract (verbatim)

"A unified policy management system for an organization including a central policy server and remotely situated policy enforcers. A central database and policy enforcer databases storing policy settings are configured as LDAP databases adhering to a hierarchical object oriented structure. Such structure allows the policy settings to be defined in an intuitive and extensible fashion. Changes in the policy settings made at the central policy server are automatically transferred to the policy enforcers for updating their respective databases. Each policy enforcer collects and transmits health and status information in a predefined log format and transmits it to the policy server for efficient monitoring by the policy server. For further efficiencies, the policy enforcement functionalities of the policy enforcers are effectively partitioned so as to be readily implemented in hardware. The system also provides for dynamically routed VPNs where VPN membership lists are automatically created and shared with the member policy enforcers. Updates to such membership lists are also automatically transferred to remote VPN clients. The system further provides for fine grain access control of the traffic in the VPN by allowing definition of firewall rules within the VPN. In addition, policy server and policy enforcers may be configured for high availability by maintaining a backup unit in addition to a primary unit. The backup unit becomes active upon failure of the primary unit."

---

Plain-Language Overview

What the patent is about

It describes a centrally managed network policy scheme for an organization with multiple sites. Instead of configuring each site's firewall/VPN/bandwidth box individually, a single policy server holds the master policy set, and each site's edge device (a "policy enforcer") gets a copy of the relevant part. The unifying technical idea is the data model: policy data lives in LDAP directories laid out as a hierarchical object-oriented tree with shared structure across the central server and each enforcer.

Key structural elements described (FIG. 2):

• A policy server domain object containing one or more policy domain objects (a policy domain = a group of enforcers sharing common policies).
• Each domain has a resource root object and a group root object.
• Resource objects: devices, users, hosts, services, time (organizable into groups with name/description/members).
• Policy objects: bandwidth, firewall, administration, and VPN policy; the VPN policy contains VPN clouds, each with sites, users, and rules (firewall rules applied inside the VPN).

The patent also covers: automatic propagation of policy changes from server to enforcers (via an ApplyLog branch of the LDAP tree, FIG. 23–25); a common compact log format (FIG. 22); dynamic VPN membership learned via routing protocols (gated/RIP) and published via LDAP (FIG. 15); downloadable self-extracting VPN client configuration (FIG. 16–17); a partitioned policy-engine architecture (FIGS. 18–21); and primary/backup high-availability units (FIGS. 26–30).

Independent claims — important caveat on uncertainty

I could not obtain authoritative claim text for this patent from the sources I retrieved. The full patent text supplied to me is truncated before the claims (it ends in the middle of the figure list, at "FIG. 27 is a flow diagram of an exemplary…"). Google Patents' indexed page for US6944183 surfaced only a "Definitions" extract, the abstract, and description — not the claims. Justia, FreePatentsOnline and Patsnap results likewise did not surface the numbered claims.

Because the operating rules require me not to fabricate, I am not going to reproduce claim language I have not seen. What I can say with reasonable confidence, inferred from the abstract, summary and specification, is the likely subject matter of the independent claims:

1. A unified policy management system claim (system-level). Likely recites: a first edge device / policy enforcer for a first network managed per policy settings in a first database; a second edge device for a second network managed per settings in a second database; and a central policy server that defines those settings and manages both edge devices from a single location, with a central database storing the edge devices' configuration information organized in a hierarchical object-oriented structure. (Abstract: "central database … organized according to a hierarchical object oriented structure.")

2. An LDAP-data-model claim. Likely recites the central database and the enforcer databases as LDAP databases all adhering to the hierarchical object-oriented structure, with resource objects (devices, users, hosts, services, time) and policy objects (bandwidth, firewall, administration, VPN grouping).

3. A VPN-grouping ("VPN cloud") claim. Likely recites a VPN policy object comprising one or more VPN clouds, each cloud including sites, users, and rules, where the rules are firewall rules providing fine-grained access control over traffic flowing through the VPN (applied to decrypted cleartext).

4. Possibly a method/change-propagation claim covering the automatic transfer of policy-setting changes made at the central server to the enforcers to update their respective databases (the ApplyLog/apply-attribute mechanism of FIGS. 23–25).

I cannot confirm (a) how many claims are in the patent, (b) which of the above are actually independent vs. dependent, (c) the exact claim 1 preamble/transition language, or (d) whether means-plus-function language is used. Anyone relying on claim scope for infringement, validity or freedom-to-operate analysis must pull the granted claim set from the USPTO PatentCenter record for 09/592,165 or the patent image PDF at patentimages.storage.googleapis.com, not from this summary.

---

Litigation / Docket Findings (including the CAFC 2026 check)

• No 2026 Court of Appeals for the Federal Circuit docket activity for US 6,944,183 was found. My searches returned 2026 Federal Circuit/PTAB material, but none referencing this patent number. Given the record shows a statutory term adjustment expiration of 2023-03-31 and "Expired – Lifetime" status, post-2023 appellate activity would be surprising, though an appeal over past damages is not strictly impossible — so treat this as "not found," not as "definitively none."
• District court litigation is recorded (per Google Patents' litigation panel, sourced from Unified Patents):
  • https://portal.unifiedpatents.com/litigation/Delaware%20District%20Court/case/1%3A14-cv-00628
  • https://portal.unifiedpatents.com/litigation/Delaware%20District%20Court/case/1%3A14-cv-00574
  • First worldwide family litigation: https://patents.darts-ip.com/?family=27585810
• Uncertainty: the search snippets did not show the parties in those two D.Del. 2014 cases, and I was unable to open the docket pages before my search budget was exhausted. I therefore decline to name plaintiffs/defendants. Both cases are from 2014, not 2026.
• The patent is cited as prior art in later filings (e.g., WO2016049376A1's search report cites the ALCATEL INTERNETWORKING family member WO 00/78004 A2 against claims 1–20), and appears in the "References Cited" lists of several later US patents — useful context if you need an invalidity/prior-art trail rather than an infringement trail.

If you want the authoritative claim set, the next steps are: (1) USPTO PatentCenter for application 09/592,165; (2) the granted-patent PDF (front page lists 709/223 and 709/225 and the examiner's cited references); (3) the D.Del. 1:14-cv-00628 and 1:14-cv-00574 dockets for the asserted claims and any claim-construction orders. I can summarize the claims verbatim once that text is available.

I'll research litigation involving this specific patent. Let me start with the leads embedded in the patent record and expand from there.

The initial searches returned noise. Let me focus on the specific leads: the two Delaware District Court case numbers embedded in the patent record, and the Unified Patents litigation portal.

Excellent — I found a strong lead. Let me verify the patents asserted and identify the second Delaware case.

Litigation Involving US 6,944,183 B1

Bottom line up front: The patent's own litigation record identifies two district-court cases, both filed in the District of Delaware in 2014. I was able to positively identify the parties in only one of them. I could not retrieve full dockets for either case before hitting my search limit, so filing dates and outcomes should be treated as not fully verified.

---

1. The two known cases (per the patent's litigation record)

The Google Patents record for US6944183B1 contains a "Family has litigation" entry linking the patent to exactly these two dockets:

Source (patent record): https://patents.google.com/patent/US6944183B1/en — the "Family has litigation" section listing Delaware District Court/case/1:14-cv-00628 and .../1:14-cv-00574, with citation "Unified Patents Litigation Data."

---

2. Case A — Alcatel-Lucent USA Inc. v. Fortinet, Inc. (1:14-cv-00574-UNA)

Confirmed from the filed complaint, captioned:

"ALCATEL-LUCENT USA INC., Plaintiff, v. FORTINET, INC., Defendant," Complaint for Patent Infringement, Civil Action No. 1:14-cv-00574-UNA, U.S. District Court for the District of Delaware.

• Plaintiff: Alcatel-Lucent USA Inc. (successor to Lucent Technologies, Inc.), Murray Hill, NJ.
• Defendant: Fortinet, Inc. (Delaware corp.), Sunnyvale, CA — accused products include the Fortigate and FortiManager series.
• Venue/venue basis: D. Del., 28 U.S.C. §§ 1391(b), (c), 1400(b).
• Patents asserted (as visible in the retrieved excerpt): U.S. Pat. No. 6,046,979 (the "'979 patent") and U.S. Pat. No. 6,098,172 (the "'172 patent"), with the list continuing ("U.S. Patent No. 6…" truncated).

Important caveat: In the portion of the complaint I retrieved, the express patent list shows the '979 and '172 patents and then cuts off. I could not confirm from the complaint text itself that US 6,944,183 was named as an asserted patent in this case — the linkage to 6,944,183 comes from the Google Patents/Unified Patents litigation record, not from the complaint excerpt I saw. The '979, '172, and '183 patents all trace to the same Alcatel Internetworking / "Fort Knox" policy-router family, which is consistent with them being asserted together, but that is inference, not confirmed record.

Source: https://www.scribd.com/document/222219131/Alcatel-Lucent-v-Fortinet

---

3. Case B — 1:14-cv-00628 (D. Del.)

The patent record links 6,944,183 to a second 2014 District of Delaware case, 1:14-cv-00628, but I was unable to retrieve a docket or complaint identifying the parties. Given the numbering and year, it almost certainly arises from the same 2014 Alcatel-Lucent USA patent-enforcement campaign in Delaware that produced the Fortinet suit, but I will not name a defendant without verification.

Source: https://patents.google.com/patent/US6944183B1/en (case/1:14-cv-00628 link)

---

4. What I did not find

• No CAFC appeal identified as involving US 6,944,183.
• No IPR/PGR at the PTAB, and no ITC § 337 investigation, identified for this patent. (Note: the '183 patent appears as a cited prior-art reference in unrelated PTAB matters such as Keysight Technologies v. Centripetal Networks, IPR2023-00445 — that is not litigation involving '183 as an asserted patent, and I'm excluding it.)
• No outcome data (settlement, dismissal, judgment) for either Delaware case in the sources I could reach.

---

5. Key patent-level facts (for context)

• Patent: US 6,944,183 B1, "Object model for network policy management."
• Application: 09/592,165; filed 2000-06-12; priority 1999-06-10; granted 2005-09-13.
• Original assignee: Alcatel SA; later Alcatel-Lucent USA Inc.; current listed assignee Nokia of America Corp. The record also shows a security agreement with Credit Suisse AG (2013), a change of name to Alcatel-Lucent, and a release by the secured party (2014).
• Legal status: Expired – Lifetime; adjusted expiration listed as 2023-03-31. Given the 2023 expiration and the 2014 filing dates, any 2014 Delaware actions are necessarily concluded, but the disposition is not established by the sources I retrieved.

---

Confidence summary

Recommended next steps to close the gaps: pull the PACER dockets for D. Del. 1:14-cv-00574 and 1:14-cv-00628 (and the corresponding Docket Navigator / Unified Patents entries) to confirm (a) the complete asserted-patent list in each, (b) the defendant(s) in 1:14-cv-00628, and (c) the termination date and disposition of each. If you want, I can attempt those targeted docket lookups in a follow-up.

I'll verify the structured ODP data against public sources before writing the report.

PTAB / AIA Trial Report — US 6,944,183 B1

Proceedings overview

Total AIA trial proceedings on file: 0 — the USPTO Open Data Portal (ODP) structured feed for US 6,944,183 B1 returns no IPR, PGR, or CBM proceedings, and my independent web verification surfaced none either; there is therefore no active / invalidated / sustained / settled / institution-denied breakdown to report, and the bottom-line defensive posture is "this patent has never been tested at the PTAB — but it is also expired (adjusted expiration 2023-03-31), so an AIA trial is now largely moot as a defensive tool and the real question for a defendant is whether any live assertion can still reach pre-expiration damages."

---

Proceedings

None — no AIA trial proceeding on file

There is no proceeding number to report. I am deliberately not supplying an IPR/PGR/CBM number, because the structured ODP block states the feed is empty and public searching confirms it. The requirements below are therefore recorded as "not applicable," with the verification trail that supports the null result.

• Type: N/A — no Inter Partes Review, Post-Grant Review, or Covered Business Method review has been instituted or even petitioned on this patent per the ODP feed.
• Filed: N/A
• Status: No PTAB activity on file (ODP, most recent ingest; independently verified 2026-09-27).
• Judge panel: N/A
• Petition grounds: N/A
• Institution decision: N/A — no petition, so no § 314(a) / § 324(a) institution decision exists.
• Final Written Decision: N/A — the PTAB has never construed a claim of this patent or issued any claim-level verdict. Do not tell a court or an adversary that any claim of the '183 patent has been canceled or confirmed by the PTAB. It has not.
• Settlement / termination: N/A
• Appeal: N/A — with no FWD, there is no CAFC appeal of a PTAB decision. CourtListener and the Federal Circuit docket show no appellate decision on this patent in my searches.
• Defensive value: Two-edged. (1) There is no PTAB precedent to cite — no FWD to hand a district court, and no claim you can say is already dead. (2) Conversely, no petitioner is burdened by § 315(e)(2) estoppel against you, so every invalidity theory remains unconstrained by prior PTAB proceedings; and because the patent expired on 2023-03-31, the practical exposure window is limited to pre-expiration damages, which materially weakens any licensing demand.

Verification trail (what I checked)

⚠️ Caveat on the litigation metadata. The Google Patents page identifies the two 2014 Delaware docket numbers and their court but not the parties or the outcomes, and my searches did not independently confirm them before the search budget was exhausted. Treat those docket numbers as leads to pull from PACER/CourtListener, not as verified litigations. I will not guess at the plaintiff — given the 2014 vintage and the Alcatel-Lucent/Nokia chain, an NPE-plaintiff scenario is plausible but unconfirmed.

⚠️ Caveat on reexamination. Ex parte reexamination is not an AIA trial and would not appear in the ODP AIA trial feed. I found no evidence of a reexamination certificate for the '183 patent, but I did not independently confirm its absence via Patent Center. If you are defending an assertion, verify this directly — an unnoticed reexam certificate could have amended or canceled claims without ever appearing in a PTAB case list.

---

Strategic summary

Claim status: untested, and now expired. No claim of US 6,944,183 B1 has been canceled, confirmed, or construed by the PTAB — there is no IPR, PGR, or CBM, and no FWD. The patent is recorded as Expired – Lifetime, adjusted expiration 2023-03-31. So the usual taxonomy (canceled / sustained / untested) collapses to a single category: all claims are UNTESTED at the PTAB, and all are now expired. Any infringement theory must be built on pre-2023-03-31 acts, and past-damages exposure (not injunctive relief) is the ceiling.

Estoppel landscape: no estoppel attaches to anyone. Because no IPR/PGR was ever filed, § 315(e)(2) estoppel is a non-issue — no petitioner, real party in interest, or privy is barred from raising any § 102/§ 103 ground, and no petitioner has been estopped from asserting invalidity in district court. Practically, that cuts both ways for a defendant: you inherit no favorable "already-adjudicated" findings, but you also face no procedural preclusion on any prior-art theory, including art a prior petitioner might have raised. The only ceiling on available grounds is the substantive one — prior art must qualify under § 102/§ 103 against the 1999-06-10 priority date, and the printed-publication/patenting bars around that date constrain the art you can actually reach.

Pattern signals: none. There is no serial petitioner (no repeat filer), no PTAB appeal history, and no defensive aggregator in the chain — Unified Patents (which is active against Alcatel-Lucent–derived assets such as the WSOU portfolio, e.g. Unified's IPRs and reexam requests on Alcatel-origin patents like US 7,333,770, US 8,103,213, US 8,179,960) has not challenged the '183 patent. That absence is itself informative: a 1999-era Alcatel Internetworking patent that was litigated in Delaware in 2014 and then allowed to expire in 2023 without ever attracting a single AIA trial suggests it was never valuable enough (or was too near end-of-life) to justify the ~$200K+ cost of a PTAB petition. On the ownership side, Google Patents lists Nokia of America Corp as current assignee, via Alcatel Internetworking → Alcatel → Alcatel Lucent (2014) → Alcatel-Lucent USA; note that a 2018 Nokia patent purchase agreement with Provenance Asset Group LLC appears in a PTAB exhibit, so confirm current ownership in the USPTO Assignment database before responding to any demand — you need to know exactly which entity (if any) holds enforceable rights.

---

Recommended next steps

1. If a demand letter cites 6,944,183 B1, lead with expiry. The patent's recorded adjusted expiration is 2023-03-31. Before engaging on the merits, demand the asserted acts, dates, and the pre-expiration damages theory. A demand resting on post-2023-03-31 conduct has no infringement case.
2. There is no FWD to link to. Because no AIA trial exists, do not cite a PTAB final written decision, and do not assert that any claim is canceled. The correct representation is: "No IPR/PGR/CBM has ever been filed against this patent; it expired 2023-03-31."
3. Confirm the null result at the source before relying on it. Pull the patent's page on USPTO PTAB E2E / the PTAB "Patent Trial" portal and Patent Center: search for (a) any AIA trial by patent number, and (b) any ex parte reexamination certificate or certificate of correction, which the AIA trial feed would not capture. A reexam that amended claims would change the entire analysis.
4. Pull the two 2014 Delaware dockets from PACER/CourtListener. 1:14-cv-00628 and 1:14-cv-00574 (D. Del.). Identify the plaintiff, defendant, asserted claims, and disposition. Two points matter: (i) if a defendant was served with a complaint alleging infringement before 2019-03-31, that party's § 315(b) one-year IPR bar ran long ago — now academic given expiry; (ii) the case outcome tells you whether the patent's claims were ever construed, and if so, whether any construction is unfavorable.
5. Map ownership before negotiating. Verify the current recorded assignee (Google Patents lists Nokia of America Corp) through the USPTO Assignment Search, and check whether the asset moved in the Nokia → Provenance Asset Group transaction. If the named demand-sender is not the recorded owner or an exclusive licensee with standing, say so.
6. If you want to preserve an invalidity record anyway (e.g., for a defense against pre-expiration damages), you can still petition for IPR against an expired patent — a claim need not be in force for the PTAB to review it — but weigh that against cost: with no injunctive exposure and a closed damages window, a district-court § 102/§ 103 defense or summary judgment is likely the better spend than a petition.
7. Do not rely on estoppel. No petitioner estoppel benefits you, and you are not estopped by anyone else's prior IPR. All § 102/§ 103 grounds against the 1999-06-10 priority date remain open, subject only to the ordinary rules of district-court invalidity practice.

Bottom line: the absence of any PTAB activity on US 6,944,183 B1 is a real, documented signal — this patent has never been adjudicated by the Board, and it expired on 2023-03-31 without ever attracting a challenge. Verify the reexam and ownership points above, confirm the 2014 docket outcomes, and treat expiry plus the empty PTAB record as the foundation of your defense rather than searching for an FWD that does not exist.

I'll research the assignment chain for this patent. Let me run targeted searches.

Let me dig into the specific assignment records and the down-chain transfers.

I hit the search-step limit before I could open the Assignment Center detail views or the docket records. Below I give you everything I could actually verify, and I mark explicitly where the record is missing rather than filling it in.

Critical sourcing note up front: The only assignment data I could actually retrieve for US 6,944,183 B1 is the Google Patents legal-events panel (which is mirrored in the authoritative full text supplied to me) plus secondary corroboration from FreePatentsOnline, Radaris and PatentLeaderboard. I was not able to load the USPTO Assignment Center detail record for this patent. Consequently I do not have reel/frame numbers, execution dates as distinct from recordation dates, or correspondent-of-record names. I will not invent them. Every reel/frame slot below reads "not retrieved," and that is a gap in my research, not a finding that the field is empty.

---

Inventors

Employer determination. The application (09/592,165) was filed 2000-06-12 with earliest priority 1999-06-10. The entity that took the inventors' assignment on 2000-10-10 was Alcatel Internetworking, Inc., which is the renamed Internet Devices, Inc. of Milpitas — the maker of the Fort Knox policy routers that Alcatel acquired (reported at ~$180M, announced early/mid 1999, folded into Alcatel's new Internetworking Group). See the contemporaneous trade coverage in Network World (June 28, 1999) and Computerwoche (March 12, 1999) describing the Internet Devices acquisition and the Alcatel Internetworking Group. The patent's own specification confirms the product lineage: the policy server and enforcers "may be implemented in a similar fashion as the FORT KNOX series of policy routers made by Alcatel Internetworking, Inc., of Milpitas, Calif."

Unusual patterns.

• Naming variant / data-quality flag: the 2000-10-10 record spells the third inventor "PANKAJ, MALVIJA" (surname rendered Malvija), while the issued patent and every other source render it Pankaj Malviya. Interpreted literally, that is a discrepancy in the USPTO index record, not a different person.
• Departure observed (post-issuance, undated): a third-party inventor profile (PatentLeaderboard) lists Pankaj Malviya as holding 3 patents associated with Juniper Networks, indicating a move away from the Alcatel/Alcatel-Lucent lineage. I could not date that move, so I cannot test the "all inventors departed within 12 months of filing" pattern. Two of three inventors have no further retrievable US filings in the Alcatel line.
• No abandonment signal found. I found no evidence of a distressed inventor-side transfer (e.g., a separate inventor-to-holding-company assignment) — the inventors assigned straight into the corporate acquirer.

---

Original assignee

Entity named on the issued patent: the front page lists Alcatel SA (Paris, FR) as original assignee (Google Patents), with the printed assignee line rendered simply as "Alcatel." The intermediate record owner was Alcatel Internetworking, Inc. (2000-10-10).

• Primary line of business: Alcatel was a French telecommunications equipment manufacturer. The relevant business unit here is Alcatel Internetworking, Inc., the enterprise-IP division assembled from Internet Devices (Fort Knox policy routers), Xylan and Packet Engines.
• Did they ship a product embodying the claims? Yes, on the face of the patent. The specification expressly identifies the FORT KNOX series of policy routers as the implementation of the policy server/policy-enforcer architecture claimed. The lineage continued commercially: Alcatel-Lucent subsequently sold the "VPN Firewall Brick" product family (e.g., Alcatel-Lucent VPN Firewall Brick 150), which appears in later litigation as an accused instrumentality — a useful corroboration that the Fort Knox/policy-enforcer line stayed in commerce long after this filing.
• Current status: operating, but no longer an independent company. Alcatel merged with Lucent in 2006 → Alcatel-Lucent (recorded here as a Change of Name, 2014-04-29). In 2014-04-29 the US operating entity recorded an assignment of interest to Alcatel-Lucent USA Inc. Nokia completed its acquisition of Alcatel-Lucent in 2016, and Google Patents now normalizes the current assignee to Nokia of America Corp. There is no bankruptcy on this chain.

---

Assignment timeline

⚠️ Caveat: the dates below are the dates as displayed in the Google Patents legal-events panel. That panel does not distinguish execution date from recordation date, and it does not publish the correspondent. I have therefore left those fields marked not retrieved rather than guessing. If you need the executed-vs-recorded dates, the reels, and the correspondents, this must be pulled from the Assignment Center detail view.

• 2000-10-10 / recorded date not distinguished in source — Reel/frame not retrieved

  • Conveyance: Assignment of Assignors' Interest (see document for details) — the original inventor→company assignment
  • Assignor: IYER, MAHADEVAN; APSANI, LAVANYA; "PANKAJ, MALVIJA" (surname misspelled in the index)
  • Assignee: Alcatel Internetworking, Inc.
  • Correspondent: not retrieved
  • Context: Initial corporate acquisition — the inventors' rights vest in the Alcatel subsidiary formed around the acquired Internet Devices business.

• 2002-11-25 — Reel/frame not retrieved

  • Conveyance: Assignment of Assignors' Interest
  • Assignor: Alcatel Internetworking, Inc.
  • Assignee: Alcatel
  • Correspondent: not retrieved
  • Context: Internal reorganization — subsidiary-to-parent upstream transfer.

• 2003-02-25 — Reel/frame not retrieved

  • Conveyance: Assignment of Assignors' Interest
  • Assignor: Alcatel Internetworking, Inc.
  • Assignee: Alcatel
  • Correspondent: not retrieved
  • Context: Internal reorganization / confirmatory or corrective record — a second, near-identical Alcatel Internetworking → Alcatel assignment approximately 15 months after the first. Two records of the same conveyance type between the same parties is a classic signature of a corrective or supplementary recording (or of a second, differently-scoped property schedule); the underlying document would be needed to tell which.

• 2013-01-30 — Reel/frame not retrieved

  • Conveyance: Security Agreement
  • Assignor: Alcatel Lucent
  • Assignee: Credit Suisse AG
  • Correspondent: not retrieved
  • Context: Securitization / debt collateral — Alcatel-Lucent pledged patent collateral to Credit Suisse. This is a lien, not a title transfer; Alcatel-Lucent retained ownership. (The same transaction, reel/frame 040788 / 0261 on the newer chain, is well documented in public patent-lending databases.)

• 2014-04-29 — Reel/frame not retrieved

  • Conveyance: Change of Name (see document for details)
  • Assignor: Alcatel
  • Assignee: Alcatel Lucent
  • Correspondent: not retrieved
  • Context: Change of name only — no change in beneficial ownership (the 2006 Alcatel/Lucent combination, recorded years later).

• 2014-04-29 — Reel/frame not retrieved

  • Conveyance: Assignment of Assignors' Interest
  • Assignor: Alcatel Lucent
  • Assignee: Alcatel-Lucent USA Inc.
  • Correspondent: not retrieved
  • Context: Internal reorganization — transfer of US-domestic patent assets to the US operating subsidiary.

• 2014-09-30 — Reel/frame not retrieved

  • Conveyance: Release by Secured Party
  • Assignor: Credit Suisse AG
  • Assignee: Alcatel Lucent
  • Correspondent: not retrieved
  • Context: Lien discharge — termination of the 2013-01-30 security interest.

No termination record for this patent. The last recorded title-holding entry is Alcatel-Lucent USA Inc. (2014-04-29). I found no recorded assignment of US 6,944,183 B1 to any Provenance Asset Group, licensing LLC, or other assertion entity, and no defensive-aggregator record.

Lead I could not close (flag for follow-up, NOT a finding): a PTAB petition file for the broader Nokia/Alcatel-Lucent divestiture references a "Patent Purchase Agreement Between Nokia Technologies Oy and Nokia Solutions and Networks BV and Alcatel Lucent SAS and Provenance Asset Group PLC/LLC," Reel 043877 / Frame 0421, with an Exhibit A schedule of assigned patents. I could not confirm whether US 6,944,183 appears on that Exhibit A — my search budget expired before I could open the exhibit. Provenance Asset Group LLC (22 West Avenue, Essex, CT) is a licensing-only entity with ~62–116 US grants recorded 2018–2020 and no evident product line, and it has been the subject of PTAB challenges. If this patent is on that schedule, the chain would end at an NPE and my verdict below would change. Verify this before relying on the verdict.

---

Timeline diagram

timeline
    title Ownership of US 6944183B1
    1999 : Provisionals filed Jun 10
    2000 : Non provisional filed Jun 12
         : Inventors assign to Alcatel Internetworking
    2002 : Alcatel Internetworking assigns to Alcatel
    2003 : Second Alcatel Internetworking to Alcatel record
    2005 : Patent issued Sep 13
    2013 : Alcatel Lucent pledges portfolio to Credit Suisse
    2014 : Alcatel renamed Alcatel Lucent
         : Transfer to Alcatel Lucent USA Inc
         : Credit Suisse lien released
    2016 : Nokia acquires Alcatel Lucent
    2023 : Patent expires Mar 31

---

NPE / troll-pattern signals

---

Verdict

Operating-company assertion — low confidence, contingent on an unresolved fact.

Rationale: the recorded chain of title runs cleanly through operating companies only — inventors → Alcatel Internetworking, Inc. (2000-10-10) → Alcatel (2002-11-25; 2003-02-25) → Alcatel Lucent / Alcatel-Lucent USA Inc. (2014-04-29) — with a lien-and-release pair to Credit Suisse AG (2013-01-30 / 2014-09-30) that never transferred title. There is no shell-entity transfer, no known NPE assignee, no cascading LLC chain, and no bankruptcy sale, which rules out the NPE categories on the recorded evidence. Alcatel Internetworking did ship products embodying the disclosed architecture (the Fort Knox policy routers named in the specification, carried forward commercially into the Alcatel-Lucent "VPN Firewall Brick" line), and the two 2014 D. Del. litigation entries sit in the same year as that internal reorganization.

Two things must be verified before you rely on this verdict:

1. The plaintiffs in D. Del. 1:14-cv-00574 and 1:14-cv-00628 were not retrievable from my sources. If an unrecorded or separately-recorded assignee (e.g., Provenance Asset Group, reel 043877/0421) is the plaintiff, the verdict flips to NPE — moderate confidence.
2. The reel/frame numbers, execution-vs-recordation dates, and correspondents in this chain are still unretrieved. Signal #3 (repeat correspondent) is the highest-yield tell and I could not score it at all.

Verify at: https://assignmentcenter.uspto.gov/ (Patent Assignment Search; the legacy Patent Assignment Search and Assignments-on-the-Web were retired 2025-09-27, so the modernized Assignment Center is now the only route). Search by patent number 6944183 and pull the reel/frame detail for each of the seven entries above.

Honest gaps in this report (do not read as negative findings): correspondent names — all links; reel/frame — all links; execution dates — all links; D. Del. party identities — both cases; Provenance Exhibit A membership — unverified.

I'll search for the patent's cited prior art and related references.

I have a partial list from FreePatentsOnline. Let me retrieve the remainder of the cited references and the foreign/non-patent citations.

Let me try to retrieve the remaining (older) cited references and the non-patent citations.

Prior-Art Analysis — US 6,944,183 B1

Exact-target search: "6944183B1" / US 6,944,183 B1. All results below refer to that specific grant. I did not substitute look-alike numbers.

⚠️ Identifier-collision warning (literal, not auto-corrected). The string "6944183" also resolves to at least two unrelated records: a Japanese patent No. 6944183 ("麻酔補助プログラム…" — anesthesia-assistance program, Univ. of Fukui, granted 2021-09-14) and a "6944183" article number in a Norwegian furniture-supplier catalogue. Neither is US 6,944,183 B1 and neither is used in this analysis.

⚠️ Date discrepancy. This task specifies "Current Date: April 26, 2026," while the session metadata states 2026-09-27. I have used neither date as evidence; no 2026 activity for this patent was found (see the previously generated section).

---

0. Threshold limitation (must be stated before any §102 mapping)

The previously generated section of this analysis correctly recorded that the granted claim set of US 6,944,183 B1 could not be obtained — the supplied full text truncates in the figure list, and the Google Patents / Justia / FPO / Patsnap retrievals surfaced only front-matter, the "Definitions" extract, the abstract and the description. Nothing in this new search changed that. I still do not have the numbered claims.

Consequently, the §102 column below cannot be a true claim-by-claim anticipation mapping. What I can legitimately do — and do below — is:

1. Give the exact list of references cited on the face of this patent (retrieved from FreePatentsOnline's "US Patent References" section for 6944183);
2. Give each reference's publication (issue) date and a brief substantive description;
3. Identify the §102 subsection under which each could operate, and
4. Map each to the claim themes inferred from the specification in the earlier section (System claim; LDAP object-model claim; VPN-cloud claim; change-propagation method claim), explicitly flagged as inference.

Any statement of the form "anticipates claim N" requires the granted claims from USPTO PatentCenter, application 09/592,165, or the front-page PDF. I am not going to invent claim numbers.

---

1. §102 framework applicable to this patent

Filed June 12, 2000 (application 09/592,165), claiming benefit of provisionals filed June 10, 1999. This is a pre-AIA analysis.

Key analytic consequence: every U.S. patent in the citation list below issued between April 2000 and July 2003 — i.e., after this patent's June 2000 filing. None of them can be §102(b) art (nothing issued more than a year before the critical date), and none can be §102(a) art. Essentially the whole list is §102(e) art, which means novelty turns on each reference's U.S. filing date, not the issue date printed below. FreePatentsOnline returned issue dates only; the filing dates were not retrieved and must be pulled from USPTO before any §102(e) conclusion is final.

---

2. Cited references — U.S. Patent References (as listed on 6944183)

Source: https://FreePatentsOnline.com/6944183.html ("US Patent References"), retrieved 2026-09-27. Order is as printed (descending issue date). Ranked ⭐ by apparent proximity to the disclosed subject matter.

Length caveat. The FreePatentsOnline "US Patent References" list was retrieved in fragments; row #31 (US 6,047,322, 2000-04-04) is where the last successful fragment ended. There are almost certainly additional, older cited U.S. patents below it (typical for a 1999-family networking patent). I also was unable to retrieve the "Foreign Patent References" and "Other References" blocks on the face of 6944183 — those would likely capture LDAP/CORBA/IETF material. This table should therefore be treated as complete for the 2000–2003 cohort, incomplete for anything earlier.

Classification correction to the earlier section: FreePatentsOnline lists the patent's classes as 370/395.5, 370/466, 370/241.1, 707/202, 709/217, 709/223–225, 370/401 — i.e., broader than the "709/223, 709/225" recorded previously. That is an enrichment, not a contradiction.

---

3. The genuinely most-relevant prior art (ranked)

If the granted claims are what the specification suggests they are (hierarchical LDAP/object model + central policy server distributing to edge enforcers), the references most likely to be §102-relevant — and the ones an examiner or litigant would lead with — are:

Secondary (relevant to specific features, not the core data model): the HA cluster-synchronisation cluster — US 6,442,713 (Block), US 6,408,399 (Baughman), US 6,272,648 (Findlay), US 6,363,498 (Howell), US 6,148,410 (Baskey) — all map to FIGS. 26–30; and the QoS/statistics group — US 6,529,499 (Doshi), US 6,047,322 (Vaid), US 6,286,052 (McCloghrie).

Non-prior-art entry to discard: US 6,210,272 (Brown, a multi-player health-education game) is field-background only; it cannot anticipate anything in this patent.

---

4. Non-patent literature cited inside the specification (potentially the strongest §102(b) art)

The specification of 6944183 expressly identifies two printed publications more than one year before the June 12, 2000 filing (both published before the June 10, 1999 priority date, and both expressly said to be "incorporated herein by reference"):

1. RFC 1777, "The Lightweight Directory Access Protocol," W. Yeong, T. Howes, T. Kille, Network Working Group, March 1995.
2. "LDAP Programming: Directory-enabled Applications with Lightweight Directory Access Protocol," T. Howes & M. Smith, Macmillan Technical Publishing, 1997.

Under §102(b) these are prior art as of their publication dates (~March 1995 and 1997), which are before both the June 1999 priority date and the June 2000 filing date. They cannot anticipate the system claims (no central policy server / edge enforcers), but they do anticipate the LDAP-mechanics sub-claims to the extent any claim is directed merely to "storing the structure as an LDAP database with DN-addressed entries."

---

5. Provisional §102 the mapping (claims unavailable — inference only)

Mapped to the four claim themes inferred in the earlier section. Every entry requires verification against the granted claims.

---

6. What I could not verify (explicit)

1. The granted claims of US 6,944,183 B1 — still unobtained. No claim-number-specific anticipation statement is possible.
2. The filing dates of all 31 cited U.S. references — only issue dates were retrievable. Because none issued before mid-1999, they are effectively all §102(e) candidates, and §102(e) turns on the filing date. Without those dates, "anticipates under §102" cannot be finally resolved.
3. The "Foreign Patent References" and "Other References" blocks on the 6944183 front page — not retrieved. A relevant EP/EPO search report (EP 1 204 259 A3) surfaced in searching and cites Goncalves et al., "Telecommunications services management with computational reflection, using CORBA and JAVA" (ITS '98, 9 Aug. 1998); EP 0 909 058 A (Sun Microsystems, 14 Apr 1999); EP 0 810 799 A (Lucent, 3 Dec 1997); and Weinstock et al., "An object-oriented approach to the management of distributed application systems," Computer Networks and ISDN Systems, 15 Dec 1997. I could not confirm that this search report belongs to the 6944183 family rather than to a sibling — treat it as a lead, not a citation of record.
4. The family's own PCT counterpart: WO 00/78004 A2 (Alcatel Internetworking Inc., published 2000-12-21) — this is the same invention, not prior art against 6944183, but it is the reference later examiners cite (e.g., against claims 1–20 of WO 2016/049376 A1). US 6,678,835 B1 and US 6,708,187 B1 are siblings.
5. Forward citations (6944183 cited by AT&T's 2014–2024 firewall family, Oracle's WS-Policy family, etc.) are not prior art and are excluded.

---

7. Recommended next steps to make this a defensible §102 analysis

1. Pull the granted claims and the full front page (including Foreign/Other References) from USPTO PatentCenter, application 09/592,165, or the patent image PDF at patentimages.storage.googleapis.com.
2. Pull each reference's U.S. filing date (USPTO PatentCenter) and confirm which are true §102(e) art (filing before 1999-06-10 / 2000-06-12).
3. Check the file wrapper (IFW) for the examiner's §102/§103 rejections and any applicant remarks — this reveals which reference the examiner actually applied to which claim, which is the cheapest ground truth available.
4. Review the D.Del. 1:14-cv-00628 and 1:14-cv-00574 dockets (Unified Patents links from the earlier section) for any asserted-claim list or IPR/invalidity contentions naming these references.

Bottom line: the clearest single-reference threats to this patent's likely independent claims are US 6,502,131 (Vaid, directory-enabled policy management) for the data-model theme and US 6,167,445 (Gai) / US 6,158,010 (Moriconi) for the centrally-defined/distributed-enforced policy theme; RFC 1777 and Howes & Smith (1997) are the only confirmed §102(b) references and would be directed at the LDAP-mechanics sub-claims. All §102 conclusions above remain provisional pending the granted claim language and each reference's filing date.

I'll first try to close the critical gap flagged in every prior section — the granted claim set — then build the §103 analysis on whatever I can verify.

The claim set is still the gating gap. Let me try Justia directly and the sibling-family claim language.

Let me make a final targeted attempt at the actual claim text.

§103 Obviousness Analysis — US 6,944,183 B1 ("Object model for network policy management")

---

0. Threshold: what I closed, what remains open (read before the analysis)

I ran six more targeted retrievals specifically aimed at the granted claim set. I still do not have the numbered claims of US 6,944,183 B1. Nothing below is a claim‑by‑claim §103 mapping, and I have not invented claim numbers. The analysis is organized by the four inferred claim themes carried forward from the earlier section, plus three feature‑level themes.

What this round did close is a materially more important gap than the claims: the earlier Prior‑Art section recorded that the patent's "Foreign Patent References" and "Other References" blocks were not retrieved (its explicit item 3). I have now recovered a substantial portion of the "Other References" (non‑patent literature) list from the Justia record for 6944183 — https://patents.justia.com/patent/6944183 (the "Once the primary and secondary units have been initialized…" fragment). This changes the §103 picture fundamentally, because every US patent on this patent's face post‑dates the critical date and is therefore only §102(e) art, whereas the NPL list contains numerous references published more than a year before the June 10, 1999 priority date — i.e., true §102(b) art usable as §103 base references against any claim.

Two further verified findings that shape the analysis:

⚠️ Identifier-collision re-confirmed. A PTAB petition file refers throughout to "the '694 Patent" (Dutta/Kumar/Lerner, AT&T Corp., issued 2004‑11‑30) — that is not US 6,944,183 B1 (issued 2005‑09‑13, Iyer et al., Alcatel). https://ptacts.uspto.gov/ptacts/public-informations/petitions/1460817/... Do not cross-contaminate the two. (That petition's prior art — Hughes and Abraham, US 5,983,270 — is nonetheless useful to us, see §9.)

---

1. Governing law and the person of ordinary skill (POSITA)

Framework: Pre‑AIA §103 applies (effective filing 2000‑06‑12; provisional priority 1999‑06‑10). Under KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), a claim is obvious where the differences between the claim and the prior art are such that the subject matter as a whole would have been obvious; the motivation to combine need not be found in the references themselves but may come from design incentives, market forces, the background knowledge of the skilled artisan, and the ordinary creativity of one skilled in the art. Graham v. John Deere supplies the four factual inquiries, and § 103(a) expressly permits combination of references that are individually only § 102(e) art (no pre‑AIA §103(c) common‑ownership shield applies here — the references are third‑party).

POSITA definition I will use (this matters enormously, because the NPL corpus is the POSITA's knowledge base):

A person with a B.S. in computer science or electrical engineering (or equivalent), plus 2–4 years of experience in enterprise network management and/or directory services — specifically familiarity with X.500/LDAP (RFC 1777 and the Howes & Smith text, both cited in the specification itself), the IETF Policy Framework working-group drafts (the policy-core-schema / Policy Core Information Model line, draft-ietf-policy-core-schema-03, 1999‑05‑17, and the Rajan framework draft, 1999‑05‑23), the DMTF Common Information Model (CIM) and Directory-Enabled Networks (DEN) information models, and the then-current firewall/VPN/IPSec and DiffServ/COPS literature, or equivalent practical experience designing firewall and VPN policy on multi-site enterprise networks.

A POSITA may be a team — the Federal Circuit permits the "combined skill" of the relevant artisans when the invention spans fields. Here the invention spans (a) directory/data‑model design and (b) packet filtering/VPN enforcement, and the notable fact is that the entire reference corpus is contemporaneous standards work by exactly those two communities.

---

2. Applicant-Admitted Prior Art ("AAPA") — the strongest single item for motivation

The '183 Background (§) contains a problem admission that functions as AAPA and supplies the motivation to combine for nearly every combination below:

"Each policy management service, however, generally requires a separate device that needs to be configured, managed, and monitored. Furthermore, as an organization grows and spreads across multiple locations, the devices maintained also multiplies, multiplying the associated expenditures and efforts to configure, manage, and monitor the devices."

And the family's JP counterpart adds the object-model concession:

"…a technique for effectively specifying and distributing policy management information across remote private networks throughout an organization generally requires a well-designed object model." (JP2003502757A)

Under KSR, the applicant's own articulation of the problem — consolidate management, and build a data model for it — is the motivation to combine. A §103 analysis therefore starts from the proposition that the POSITA had an affirmative reason, recited by the inventor, to unify policy management across sites via a shared directory model.

---

3. Date-profile triage of the reference corpus (why the NPL carries the load)

The earlier section's table of 31 US patents (issue dates 2000‑04 through 2003‑07) is correct as to what it covers, and I agree with its conclusion: none issued before mid‑1999, so all are §102(e)‑only. The newly recovered NPL block is where §102(b) and §102(a) art lives. Triage:

Three anomalies to flag before anyone relies on this list:

1. ⚠️ "DMTF LDAP Schema for the CIM v2.4 Core Information Model v1.0, May 6, 2002" and "Policy Core Information Model—Version 1 Specification, RFC 3060, Feb[ruary 2001]" appear in the reference block yet post-date the June 12, 2000 filing. They therefore cannot be prior art against '183. Their presence suggests the Justia "References Cited" block aggregates family/continuation IDS material, or that these were cited in a later prosecution. Do not plead these as §102/§103 art.
2. ⚠️ "Common Information Model (CIM) Specification, Version 2.2, DMTF, June 14, 1999" — four days after the June 10, 1999 provisional filing. It is not §102(e) art (it is not a US patent/application), and it is §102(a) art only if the applicant's invention date post-dates 1999‑06‑14. The operative CIM art is the earlier release line (v2.1/v2.0 and the CIM Network Services sub-models listed above, dated Jan/Feb 1998), which is §102(b). Anyone building this defense must verify the exact CIM release dates rather than rely on v2.2.
3. ⚠️ "Policy-Based Networking: Working Hand In Hand with DEN," ENTmag.com, Nov 1988 — the 1988 date is almost certainly an OCR/typographical corruption of 1998. Either reading yields §102(b) art, so the conclusion is unaffected; but cite it carefully.

---

4. Claim themes under test (carried forward and extended)

From the prior section: Theme A (unified system: two edge devices + central policy server + central DB of enforcer configuration), Theme B (LDAP data model — both server and enforcer DBs adhering to one hierarchical object-oriented structure, with resource objects and policy objects), Theme C (VPN cloud abstraction with sites/users/rules), Theme D (automatic propagation of policy changes from server to enforcers). I now add:

• Theme B1 — resource-object taxonomy: devices, users, hosts, services, time (each groupable with name/description/members).
• Theme B2 — policy-object taxonomy: firewall, bandwidth, administration, VPN policies, defined by association of resource objects.
• Theme B3 — policy domain object: a grouping of policy enforcers that share common policies.
• Theme E — partitioned enforcement engine (stream table → protocol classification → policy engine → forwarding/IPSec/bandwidth modules).
• Theme F — common log format / statistics aggregation from enforcers to server.
• Theme G — high-availability primary/backup units with keep-alive and config synchronization.

---

5. The §103 combinations

Each combination states: the references, what each contributes (flagged by evidence quality), the articulated motivation (KSR-style), reasonable expectation of success, and confidence.

Combination 1 — The core data model (attacks Themes B, B1, B2, B3)

Vaid et al., US 6,502,131 + Strassner/Ellesson/Moore, Policy Framework Core Information Model (1999‑05‑17) + DEN Information Model & Base Schema (1999) + RFC 1777 / Howes & Smith (1995/1997) (± Ford, Multiple Policy/Domain Environment (1995) for B3; ± Koga et al. (1999‑03‑11) for the extensible-schema point).

Motivation to combine: KSR-clean. (a) The applicant's own background admits the need to unify multi-device policy management and the JP family member admits a "well-designed object model" was required. (b) The IETF and DMTF had already published the object model and the directory mapping — the standards bodies were converging on "policy = objects; objects = directory entries," which is precisely the "predictable variation" KSR endorses. (c) Using LDAP rather than a proprietary store was the design incentive: LDAP provided standardized schema, replication, and query at no development cost. (d) No change in the principle of operation — Vaid's directory-enabled policy tool continues to operate as intended when the directory schema is populated with the DEN/CIM object classes.

Reasonable expectation of success: High. Both the DEN/CIM schema work and LDAP implementations were mature by 1999.

Confidence: Medium-High for Themes B/B1/B2 as §103 (not §102) — this is a textbook "arrange known elements per known methods" case. Medium for B3 (the "policy domain = grouping of enforcers sharing policies" sub-limitation) — Ford supports it, but the enforcer-grouping framing is a step beyond generic "policy domain."

---

Combination 2 — Central definition / distributed enforcement (attacks Theme A)

Moriconi et al., US 6,158,010 (Maintaining security in a distributed computer network) + Gai et al., US 6,167,445 (Defining and implementing high-level QoS policies in computer networks) + Bahlmann, US 6,487,594 (Policy management method and system for ISPs) + Sun, "Internal Firewalls…" (1997‑06‑01) + Apostolopoulos et al. (1997‑10) + Cisco Secure Policy Manager (1999‑05‑08).

Motivation to combine: The applicant's admission that per-site devices "multiply… expenditures and efforts" is the express motivation. Sun supplies the deployment topology (a firewall at each subnet edge); Gai supplies the central authoring/distributed implementation; CSPM supplies commercial proof that the combination was the industry's destination in 1999. KSR: "a court must ask whether the improvement is more than the predictable use of prior art elements according to their established functions." Here it is not.

Reasonable expectation of success: High; commercially demonstrated by May 1999.

Confidence: Medium-High. The only genuinely vulnerable element is whether the art recites the two-database mirror ("respective portions of the policy server database are copied to the policy enforcer databases") rather than mere client-server policy download — see §8.

---

Combination 3 — The resource/policy taxonomy, including "time" and "role" (attacks Themes B1, B2, and the administrative-policy sub-theme)

Mandal et al., US 6,170,009 (Controlling devices on a network through policies) + Dutcher et al., US 6,311,205 (Persistent user groups on servers managed by central servers) + Rowe et al., US 6,466,941 (service table database) + Doshi et al., US 6,529,499 / Vaid et al., US 6,047,322 (QoS) + "Signaled Quality of Service," v0.0‑14 (Jan. 1998) + "Network Services—Internet Protocol Security," v0.0‑2 (Feb. 1998) + "DHCP Service," v0.0‑1 (1998‑02‑18).

• Devices → Mandal '009 (devices represented and controlled through policy objects).
• Users / user groups → Dutcher '205 (persistent, centrally administered user groups — the "group name, description, and member information" limitation).
• Services → Rowe '941 (service table database with uniquely-defined service entries) + "DHCP Service" CIM model (1998‑02‑18) which is literally a service object schema.
• Bandwidth policy → Vaid '322 / Doshi '499 + "Signaled QoS," CIM, Jan. 1998 (a QoS model object).
• VPN policy → "Network Services—Internet Protocol Security," CIM, Feb. 1998 (an IPsec service model).
• Time → the weakest link; see §8.

Motivation: Once one accepts a directory-object model (Combination 1), populating it with the known dimensions of traffic classification is a straightforward enumeration. Sun (1997) frames firewalls in terms of source/destination/service; the DMTF CIM Network Services sub-models (all 1998, hence §102(b)) had already reduced QoS and IPsec to schema objects. The applicant did not invent the idea that QoS and IPsec/VPN can be modeled as data objects — the DMTF had published exactly that a year earlier.

Reasonable expectation of success: High.

Confidence: Medium-High for bandwidth/firewall/VPN policy objects and users/devices/services resources; Medium for the specific five-element taxonomy as a closed set (the patent uses "preferably include," which is permissive — a claim requiring exactly {devices, users, hosts, services, time} would be harder to reach; a claim using "comprising" would be easy).

---

Combination 4 — Change propagation / ApplyLog (attacks Theme D)

Birkler et al., US 6,516,314 (Optimization of change log handling) + Westfall et al., US 6,449,650 (Deploying QoS policies on a data communication network) + Koga et al. (1999‑03‑11) + DEN (1999).

Birkler is the standout: it is a change log applied to a networked data store, which is structurally the '183 FIGS. 23–25 mechanism (an ApplyLog branch, per-administrator and per-device log DNs, an apply attribute accumulating values, deletion of the attribute on successful acknowledgment).

Motivation: The applicant's own specification supplies it — "the policy server creates a log of the changes … for later distribution to the policy enforcers." Once two directories must hold the same structure (Combination 1), change-log-based synchronization is the known method for propagating changes; the §102(e)-eligible Birkler reference optimizes exactly that. Alternatively, ordinary replication (LDAP replication protocols) achieves the claimed result, and "a claim to a known process is not patentable merely because it is implemented with a computer" or, here, in a directory.

Reasonable expectation of success: High.

Confidence: Medium for §103 (Birkler supports the change-log concept; whether it supports the apply-button-triggered batch distribution to a subset of enforcers with acknowledgment-based log deletion — FIG. 25 steps 428–438 — requires the reference text, which I have not retrieved).

---

Combination 5 — The VPN "cloud" abstraction (attacks Theme C — the hardest theme)

Sitaraman et al., US 6,243,749 (Dynamic network address updating) + Braun, Günter, Kasumi & Khalil, "Virtual Private Network Architecture," CATI — Charging and Accounting Technology for the Internet, 1999‑01‑08 + Blight & Hamada (1999‑05‑24/28) + Nomura et al., "A Policy-Based Networking Architecture for Enterprise Networks" (1999).

• Sitaraman '249 — dynamic updating of network-address/route information (maps to the FIG. 15 gated/DNMonitor route-publish mechanism).
• Braun et al. (1999‑01‑08) — a published VPN architecture; §102(a) art and the best available candidate for the notion of a VPN defined as a group of member sites/networks rather than pairwise tunnels.
• Blight & Hamada / Nomura et al. (both 1999, both §102(a)) — policy-based networking architectures spanning large-scale enterprise/public interoperation, i.e., multi-site policy scope.

Motivation: The applicant's own statement of benefit — "the network administrator need no longer manually configure each possible connection in the VPN, but only need to create a VPN cloud and specify the sites, users, and rules" — describes a labor-saving administrative abstraction, which is a classic non-technical/UX-driven motivation that KSR treats as legitimate ("the desire to enhance… commercial opportunities" and known design incentives). Given a directory object model (Combination 1) and Braun's VPN membership concept, defining a "VPN cloud" object containing sites/users/rules is the predictable next step.

Reasonable expectation of success: Medium-High.

Confidence: Low-Medium. No retrieved reference squarely discloses the three-part cloud object (sites + users + rules) with firewall rules applied to decrypted cleartext inside the tunnel. This is the narrowest and most defensible part of the patent. If any claim is limited to the VPN-cloud structure, it is the claim most likely to survive a §103 challenge on this record.

---

Combination 6 — Partitioned enforcement engine (Theme E)

Jackowski et al., US 6,141,686 + Narad et al., US 6,157,955 + Bhattacharya et al., US 6,587,466 + McCloghrie et al., US 6,286,052 + US 6,148,336 (Thomas — layered service provider / plugin ordering) + Braun et al. for the VPN endpoint function.

Narad discloses a policy engine having a classification unit — FIG. 19's policy engine 510 + FIG. 20's protocol classification engine 508 combined. Jackowski discloses application/protocol classification with per-user and per-service traffic statistics — the log-format and statistics themes (F) as well. Thomas teaches ordering multiple layered enforcement plugins with traffic filtering — the partitioned, sequentially-applied engine architecture (stream table → classification → policy engine → forwarding/IPsec/bandwidth).

Confidence: High at feature level. Note, however, that partitioning for hardware implementation is stated in the patent as a design goal; if a claim recites the partition as an architectural limitation, §103 is strong (predictable, functionally-divided implementation).

---

Combination 7 — High availability (Theme G)

Block et al., US 6,442,713 + Baughman, US 6,408,399 + Findlay et al., US 6,272,648 + Baskey et al., US 6,148,410 + Howell, US 6,363,498 + RFC 2281, HSRP (March 1998 — §102(b)) + Li et al.'s HSRP specifically for the keep-alive/standby-takeover protocol.

HSRP is the strongest item: it is a standardized, widely deployed standby-router protocol with periodic hello/keep-alive and active-takeover semantics — functionally identical to the FIG. 26–27 heartbeat/KEEP_ALIVE/takeover described in '183. Add Howell '498 (automatic backup of switch system files → config sync) and Findlay '648 (inter-server heartbeat).

Motivation: Redundant-unit failover was standard practice; and the applicant's own sibling patent (US 6,678,835) explains the motivation verbatim — "For such a unified policy management system to be effective, the various components of the system should be reliable and fail proof."

Confidence: High for §103 at feature level. Note the sibling patent '835 is separately claimed to this HA subject matter, which suggests '183's claims may not be directed to HA at all (the Summary of '183 mentions HA only in the abstract). Treat Theme G as relevant only if '183 has dependent claims reaching it.

---

6. Cross-cutting motivation-to-combine catalog (for the record)

---

7. Non-obviousness arguments the patent owner would (and should) press

A rigorous §103 report must state where the defense is weak. On this record, the patent owner's best arguments are:

1. The two-directory mirror with a shared structure. The claim theme is not merely "a policy server sends policy to devices" (Cisco/PCIM art at C2) but that the same hierarchical object structure is instantiated in both the central database and each enforcer database, with only portions copied — and that the enforcer tree deliberately omits the policy-server-domain and policy-domain objects. No retrieved reference is shown to disclose this structural partitioning, which is a genuine architectural choice with a stated purpose. This is the most likely locus of non-obviousness. ⚠️ But see the caveat in §0 — I do not have the claims, so I cannot tell whether this is actually claimed.
2. The VPN cloud (three-part object, cleartext firewall rules inside the tunnel). Nothing retrieved discloses it. C5 is the weakest combination.
3. "Time" as a first-class resource object. The IDS list contains nothing squarely teaching a time-dimension object; this would have to come from the uncited Abraham reference (see §8) or from general firewall-practice evidence. A dependent claim reciting a time-group object could survive.
4. The specific ApplyLog DN/attribute mechanism (per-administrator node, apply attribute accumulating A_L1, A_L2…, deletion on ACK). If claimed with that specificity, C4 is insufficient on this record.
5. The allowance itself. The examiner allowed the case over the art on the face of the patent. That is weak evidence of non-obviousness (it establishes only that the art of record was considered, not that the claims are valid; and three items in the reference block post-date the filing, which suggests the IDS/allowance record is muddled), but it is a point the owner will make. Prosecution history was not retrieved — I cannot confirm which references were actually applied against which claims, and this is the single highest-value remaining document.

---

8. Additional candidate art not on the patent's face (worth pursuing)

• US 5,983,270 — Abraham et al. (AT&T), issued 1999‑12‑07, filed 1997 → available as §102(e) art (verify filing date < 1999‑06‑10). Per the retrieved PTAB petition excerpts, Abraham discloses a GUI policy manager in which an administrator/mid-level administrator/manager applies protocol policies, site policies, file type policies, quota policies, and time scheduling policies, and where a filter engine in a network server inspects source/destination IP and port and allows/denies/logs. This maps onto '183's (i) administration policy with a role attribute, (ii) site concept, (iii) services objects, and (iv) the time resource object — i.e., it supplies the two items §7(3) above identifies as the patent's strongest gaps. Recommend verifying Abraham's full text before relying on it (my characterization comes from a different IPR petition, not from Abraham itself). Source of the excerpts: https://ptacts.uspto.gov/ptacts/public-informations/petitions/1460817/download-documents?...
• Marriott & Sloman (1996) and Sloman's later work — the canonical authorization/obligation policy-object literature; useful for a "policy object" anticipation/obviousness argument predating the encryption-and-VPN framing.
• "Directory-enabled Networks" + "Chaudhury et al., Directory Schema for Service Level Administration…" — the latter is a direct precedent for "a directory schema for service-level policy," closing the gap between generic DEN and the claimed resource/policy taxonomy. Its date must be verified.
• RFC 3060's lineage (draft-ietf-policy-core-schema) — locate the −00 and −01 drafts; if any predates 1999‑06‑10, they are §102(a)/(b) art and are the closest thing to the claimed object model in existence.

---

9. Confidence summary

---

10. Recommended next steps to convert this into a defensible §103 opinion

1. Obtain the granted claims. USPTO PatentCenter, application 09/592,165, or the patent image PDF. Nothing here should be filed or relied on until then. Every "theme" label above is an inference from the Summary, the JP family member, and the sibling '835 claim format.
2. Obtain the file wrapper (IFW). This gives the examiner's actual §102/§103 rejections, the references applied to which claims, and the applicant's remarks. It is the cheapest ground truth and it will reveal whether any of C1–C7 was actually traversed.
3. Verify the §102(b) dates for: Sun (1997‑06‑01), Apostolopoulos (1997‑10), Ford (1995‑08), Marriott & Sloman (1996), Estrin & Steenstrup (1991), Pohlmann (1997), RFC 2281 (1998‑03), and the four DMTF/CIM Network Services sub-models ("DHCP Service," "Network Services—IPSec," "Signaled QoS," "SNMP," all Jan/Feb 1998). These are the references that survive the June 10, 1998 critical date and are therefore the safest §103 anchors.
4. Verify the filing dates of the §102(e) US patents used (Vaid '131, Moriconi '010, Gai '445, Mandal '009, Dutcher '205, Birkler '314, Westfall '650, Narad '955, Jackowski '686, Sitaraman '249, Howell '498, Block '713) — several plainly issued on pre‑1999‑06‑10 applications, but the filing date, not the issue date, controls.
5. Pull the D. Del. dockets 1:14-cv-00574 and 1:14-cv-00628. If US 6,944,183 was asserted, the defendants' invalidity contentions likely already contain a §103 chart built on this corpus — worth comparing against C1–C7, and it may reveal art not on the patent's face.
6. Isolate and discard the three post-filing references (DMTF LDAP Schema for CIM v2.4, 2002‑05‑06; RFC 3060, Feb 2001; and, on the §102(a) analysis, CIM v2.2 of 1999‑06‑14) so they never appear in an invalidity contention.

Bottom line. On the art actually retrieved, US 6,944,183 B1's likely independent claim is a strong §103 target and a weak §102(e) target. The system-level theme is met by Moriconi/Gai/Bahlmann plus the 1997 Sun firewall-at-subnet-boundary paper and Cisco Secure Policy Manager, with the applicant's own background supplying the motivation. The directory object-model theme — the very point the family's JP member identifies as the reason the invention was needed — is met by Vaid's directory-enabled policy tool combined with the IETF Policy Core Information Model draft (1999‑05‑17), DEN, and the LDAP references the specification itself incorporates. The VPN "cloud" object is the exception: nothing retrieved discloses it, so if the claims are narrowed there, the §103 case weakens sharply. All of this is contingent on the granted claim language, which I could not obtain and did not invent.