US 6816903

Patent Overview: US6816903B1

Title: Directory enabled policy management tool for intelligent traffic management

Patent number: US6816903B1
Application number: US09/454,147
Filing date: 1999-12-03
Publication/grant date: 2004-11-09
Prior art date: 1997-05-27
Priority date (stated as an assumption): 1997-05-27; an external priority claim from US08/999,517 (1997-12-29) is noted
Inventors: Gregory Rakoshitz, Sanjeev Rao Putta, Aseem Vaid
Original assignee: Novell Inc. (earlier assignment to Ukiah Software, Inc., 2000-03-13)
Current assignees listed: Micro Focus Software Inc.; JPMorgan Chase Bank NA
Legal status: Expired – Fee Related; anticipated expiration 2019-12-03

Classifications: H04L47/00 and H04L47/10 (traffic control; flow control/congestion control); H04L47/24 and H04L47/2441 (traffic attributes such as priority/QoS; flow classification); H04L47/20 (traffic policing); H04L47/2475 (traffic by application type); H04L41/00, H04L41/08, H04L41/0894 (policy-based network configuration management); H04L41/50, H04L41/5003, H04L41/5019, H04L41/5022 (network service management; SLA and QoS management); H04L41/508, H04L41/509 (managed services, including media content delivery); H04L43/00 (monitoring/testing of data switching networks).

Purpose and plain-language scope (from the supplied text): The title and classifications indicate a directory-enabled policy management tool directed to managing network traffic intelligently—classifying traffic flows by attributes such as priority, QoS, or application type, and applying policies (including policing and policy-based configuration) within data switching networks. The prior-art keywords listed are "information," "traffic," "flow," "policy," and "network."

Source: https://patents.google.com/patent/[US6816903](/patent/US6816903)/en

What the excerpt does not establish: It contains no abstract, claims, specification, or drawings, so the precise claimed scope cannot be stated from this text. Dates marked as assumptions are not confirmed legal conclusions. The listing of assignees "may be inaccurate"; no legal analysis of status is represented. The excerpt does not establish litigation, validity, or prior-art content.

I'll research litigation involving US patent 6816903 across patent litigation sources.

Initial searches surfaced no litigation for this patent. Let me search more targeted sources.

Let me search directly on litigation databases and the patent's own litigation records.

Findings: Litigation Involving U.S. Patent No. 6,816,903

Bottom line: I found no record of any litigation involving U.S. Patent No. 6,816,903. Based on the searches I was able to run, I cannot identify any district court case, ITC action, or Federal Circuit appeal in which this patent was asserted.

What the searches returned (and why each hit was not litigation for this patent)

I also searched for assertion activity by the patent's owners of record — Novell, Inc., Ukiah Software, Inc., and current assignees Micro Focus Software Inc. / JPMorgan Chase Bank N.A. — without finding any pleaded or reported case tied to the '903 patent.

Patent identification (for the record, so the number is not conflated with others)

• US 6,816,903 B1 — "Directory enabled policy management tool for intelligent traffic management"
• Application No. 09/454,147, filed 1999-12-03, granted 2004-11-09
• Inventors: Gregory Rakoshitz, Sanjeev Rao Putta, Aseem Vaid
• Original assignee: Novell, Inc. (previously Ukiah Software, Inc.)
• Priority: claimed from US 08/999,517 (later US 6,578,077), which claims priority to provisional 60/067,857 and 60/047,752, earliest priority date 1997-05-27
• Legal status: Expired – Fee Related; anticipated expiration 2019-12-03

Important caveats

1. Not a guarantee of no litigation. My universe here was limited to the web searches I could complete. Comprehensive negative clearance on a patent requires Paid PACER/Docket Navigator/RPX or Lex Machina queries, the USPTO Patent Center "Litigation" / Global Dossier view, and the Unified Patents litigation portal (portal.unifiedpatents.com/litigation) filtered to exactly 6816903. I was unable to open those portals directly.
2. Because the patent's priority reaches back to May 27, 1997 and it issued in 2004, it would have expired (pre-URAA filing considerations aside, the record shows expiration on 2019-12-03). The practical window for assertion was roughly 2004–2019; nothing surfaced from that window.
3. I did not find any PTAB proceeding (IPR/PGR/CBM) or ITC Section 337 investigation naming this patent either — but again, I could not query PTAB directly.

Recommended next steps to confirm

• PACER Case Locator / CourtListener RECAP search on "6,816,903" and "6816903".
• Unified Patents portal → Litigation → search patent number 6816903.
• USPTO Patent Center → Patent No. 6816903 → "Litigation" and "Post-Grant" tabs.
• MaxVal / Lex Machina / RPX Insight if you have access, filtering for all four owners of record (Ukiah Software, Novell, Micro Focus Software, JPMorgan Chase as assignee-of-record).

If you can grant me another round of tool access, I'll run the exact number strings (6816903, 6,816,903) against the Unified Patents and CourtListener litigation endpoints and report any hits with plaintiff, defendant, jurisdiction, case number, filing date, and status.

I'll verify the structured "no proceedings" data point with targeted searches before writing.

Let me run a few more targeted checks to be thorough.

Method note

The canonical source is the structured "PTAB proceedings on file" block in the task prompt: the USPTO Open Data Portal (ODP) returns no AIA trial proceedings for US 6,816,903. I ran independent web searches (patent number, "IPR," "PTAB petition," "Unified Patents," assertion/litigation searches) to try to surface anything the ODP ingest might have missed. No AIA trial petition, institution decision, FWD, or appeal naming US 6,816,903 surfaced. I found no proceeding number to report, and I will not manufacture one.

---

Proceedings overview

Total AIA trial proceedings on US 6,816,903: 0. Breakdown by status: 0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution denied. The bottom-line defensive posture is not "the patent survived two IPRs and is hardened" and not "claims 1-5 are cancelled" — it is "untested at the PTAB, and now moot for prospective enforcement." No claims have been cancelled by the Board, no estoppel attaches, and no FWD exists to cite; but the patent itself expired on 2019-12-03 for failure to pay maintenance fees, which caps any live exposure to past (pre-expiration) infringement only.

---

Proceeding-by-proceeding

None to report. There is no ### {PROCEEDING_NUMBER} — {Petitioner} v. {Patent Owner} entry for this patent because the ODP structured block contains zero AIA trial records and no search result contradicted that.

For completeness, here is what I did find involving the number, none of which is a proceeding against this patent:

I flag the last row deliberately: 8,073,681 and 6,816,903 are different patents. Anyone doing a quick string search across PTAB papers will hit IPR2020-01367 and be tempted to attribute it here. It does not belong here.

---

Strategic summary

Claim status: fully untested. Because no petition was ever filed, every claim of 6,816,903 stands unadjudicated — none cancelled, none confirmed, none narrowed by disclaimer or certificate. There is no surviving-claim list to give you, because there is no cancellation to survive. One small evidentiary datapoint that bears on the prior generation's open question about claim scope: the EPO search report on EP 2028787 A1 cites "claims 1–6" of US 6,816,903, which indicates the patent carries at least six claims and that foreign examiners treated the disclosure as material prior art. That is a citation artifact, not a claim construction, and it does not substitute for the official claim set at USPTO PatentCenter — the open item flagged in the earlier section remains open.

Estoppel landscape: wide open. 35 U.S.C. § 315(e)(2) estoppel is triggered only by a petitioner that reaches a final written decision. Here, no petitioner exists, so no estoppel binds anyone, and the full pre-AIA prior-art universe — § 102(a), (b), and (e) references, and § 103 combinations under KSR — remains available as a defense. Note that this patent's 1997 priority / 1999 filing means pre-AIA §§ 102/103 apply, so § 102(e) prior art is measured against the pre-AIA case law (including In re Hilmer and its treatment of foreign priority dates). Practically, though, validity is the least of your concerns: see below.

Pattern signals: none. No repeat petitioner (there was no first petitioner), no patent-owner PTAB appeal activity, and no defensive aggregator such as Unified Patents anywhere in the chain. The chain is entirely conventional: Ukiah Software → Novell (2001) → Micro Focus Software Inc. (2016 name change) → JPMorgan Chase Bank, N.A. as security-interest successor agent (2017). The patent lapsed on 2019-12-03, and its sibling US 6,578,077 (same inventors, "Traffic Monitoring Tool for Bandwidth Management") shares the same pedigree — worth checking separately if a demand letter cites the family, since the earlier generation confirmed that patent is the closest relative.

The real defense is the expiration date, not validity. 6,816,903 is expired for failure to pay maintenance fees as of 2019-12-03. Two consequences dominate any PTAB strategic analysis:

1. No prospective infringement. An expired patent cannot be infringed going forward, so any injunction demand or ongoing-royalty theory is meritless on its face.
2. Recovery is capped by § 286. For past conduct, damages reach back only six years before the filing of an infringement complaint, i.e., roughly to late 2019 at the earliest for a hypothetical 2026 filing — which is essentially the expiration date itself. The practical damages window for this patent is therefore near zero.

An AIA trial is also structurally unavailable as a tool here: PGR is limited to patents with an effective filing date on or after 2013-03-16 (§ 321), and this patent's effective filing date is 1999 (priority 1997). CBM review under AIA § 18 sunset for petitions filed after 2020-09-16, and in any event a CBM would have required the claims to be directed to a covered business method in the financial-services space. That leaves only IPR (§§ 311–319), which is technically available against an expired patent — the Board will institute, but claim amendment under § 316(d) is unavailable once the patent expires, and the 12-month FWD clock from institution (§ 316(a)(11)) applies. Paying PTAB fees to invalidate an already-expired patent is rarely the right economic move unless you need an estoppel-generating or collateral-estoppel-generating ruling in parallel litigation.

---

Recommended next steps

If you are a defendant and have received a demand letter or complaint citing 6,816,903:

1. Lead with expiration, not validity. Confirm the lapse on the face of the record — the Google Patents legal-status entry states "Expired – Fee Related" with "Anticipated expiration 2019-12-03" (source: patents.google.com/patent/US6816903B1/en, fetched 2026-09-24). Verify the maintenance-fee status independently at USPTO PatentCenter before relying on it in correspondence, and check whether the fee window could have been, or was, revived under 35 U.S.C. § 41(c). Because there is no FWD to quote, you cannot say "claims have been cancelled" — do not imply it. The correct representation is: the patent has expired, no claim has ever been adjudicated invalid, and liability can attach only to pre-expiration acts within the § 286 lookback.
2. Demand the asserted claim numbers. The prior analysis could not confirm the claim text. There is no PTAB record constraining the patentee to a narrowed claim, so you must litigate whatever is asserted. Pull the official claim set from PatentCenter and, for the record, note that the EPO search report on EP 2028787 A1 treats claims 1–6 as the relevant claim range of this document.
3. If the demand cites a sibling patent from the same family, check that patent separately. The family (US 6,578,077; US 6,502,131; provisional 60/110,976; 60/067,857; 60/047,752) has its own PTAB posture, which is outside the scope of the structured data for this patent. My searches did not cover it conclusively, and I will not assert its status.
4. Ex parte reexamination (§ 302) is your only realistic USPTO avenue if you need an invalidity adjudication rather than a damages defense — but weigh the expense against the near-zero damages exposure.

On the "absence of IPRs" signal: the task framing suggests that well-asserted patents eventually attract IPRs. That inference should be applied carefully here. This patent appears to have never been commercial-asserted in the US litigation I could find, so there was no petitioner with a § 315(b) trigger — the absence of IPRs is consistent with a patent that was never worth attacking, not with a patent that resisted attack. That distinction matters: you cannot infer robustness from the empty docket the way you could for a patent that survived institution denials.

Verification and caveats:

• No PTAB proceeding on US 6,816,903 exists in the USPTO ODP structured data or in any search result I reached. I cannot positively prove a universal negative, and ODP indexing can lag newly filed petitions — if a petition were filed within roughly the last few weeks, the ODP ingest might not show it. Re-check via PTAB E2E / Patent Trial and Appeal Board End to End and the PTAB Decisions page before relying on "no proceedings" in a filing.
• Contradiction flag: nothing in this analysis contradicts the previously generated sections. It reinforces their two open caveats — the verbatim claim set is still unconfirmed, and the absence of any CAFC 2026 docket activity is consistent with the absence of PTAB activity, since there was no FWD to appeal.

Links cited:

• Patent record (abstract, specification, legal status): https://patents.google.com/patent/[US6816903B1](/patent/US6816903B1)/en
• USPTO PatentCenter (authoritative claim set, fee/maintenance status): https://patentcenter.uspto.gov
• PTAB E2E (proceeding search): https://ptacts.uspto.gov/ptabweb
• PTAB Decisions: https://www.uspto.gov/patents/ptab/decisions
• Samsung petition citing Rakoshitz/6,816,903 as prior art (different patent under review): https://ptacts.uspto.gov/ptacts/public-informations/petitions/1556641/download-documents
• EPO search report citing US 6,816,903 against claims 1–6: https://patentimages.storage.googleapis.com/a9/1c/8c/de4a6a68ae1b88/EP2028787A1.pdf
• IPR2020-01367 — different patent, US 8,073,681 B2 (cited only to flag the misreading risk)
• CourtListener (for any future CAFC docket): https://www.courtlistener.com

I'll research the assignment chain and ownership history for this patent before writing the analysis.

Ownership Chain Reconstruction — US 6,816,903 B1

Sourcing caveat (read first). I could not reach assignmentcenter.uspto.gov or the legacy assignment.uspto.gov index directly in this session; both render via JavaScript and returned no retrievable records. What I have instead is the Google Patents "Legal Events" panel, which is itself populated from the USPTO assignment recordation database (and is what the "Assignments" tab on the Google Patents page links to). That panel gives conveyance type, assignor, assignee, and recording date, and — critically — it does not expose reel/frame numbers or the correspondent of record for most entries. Where a reel/frame appears below, it is because the conveyance description itself names the reel being released; I have flagged those. I cannot supply correspondents for this chain, and I will not invent them. Any reel/frame or correspondent field not shown below must be pulled from the Assignment Center record itself.

I also confirm, consistent with the prior section, that the patent's own cross-references and the Google legal-event panel are the only ownership evidence I reached. No reel/frame numbers were fabricated below.

---

Inventors

Pattern note (and a timing oddity worth flagging): The application was filed 1999-12-03, which is after Novell announced its acquisition of Ukiah Software in June 1999 (multiple contemporaneous press reports: Computerworld, Computable.nl, Tech Monitor; Novell's own acquisition of Ukiah is confirmed by the Network World retrospective on ZENworks for Networks). Yet the inventors' assignment ran to Ukiah Software, not Novell, and was recorded 2000-03-13, with Ukiah's onward assignment to Novell recorded 2001-06-07. This is the classic post-acquisition chain-of-title cleanup (the inventors' original employment obligation ran to Ukiah; Novell then took a confirmatory assignment from Ukiah), not an inventor-departure/fire-sale pattern. I found no evidence that any of the three inventors left within 12 months of filing, and I would not infer one.

Contradiction flag vs. the prior section: Google's legal-event panel annotates the 1999-12-03 filing as "Application filed by Novell Inc." That label is inconsistent with the recorded inventor→Ukiah assignment dated 2000-03-13. The patent's face lists Novell, Inc. as assignee, but the paper chain of title runs through Ukiah Software first. Treat the "filed by Novell Inc" tag as a database artifact, not evidence that Novell was the filing-time owner.

---

Original assignee

• Entity named on the issued patent: Novell, Inc. (Provo, Utah).
• Product embodying the claims: Yes. The disclosed tool is Ukiah Software's NetRoad TrafficWare (first Windows-NT-based IP bandwidth monitoring/control product, directory-enabled via LDAP — Computing, Jan/Mar 1998), which Novell folded into ZENworks for Networks and its directory-enabled Firewall for NT (Network World; Computerwoche, Sept. 1999). The specification itself calls out "a TrafficWare™ firewall server 110 from Ukiah Software, Inc."
• Primary line of business: Network operating systems and directory services (NetWare, NDS/eDirectory, GroupWise, ZENworks).
• Current status: Not operating under the Novell name. The corporate lineage is:
  • June 1999 — Novell acquires Ukiah Software (price not officially disclosed; one report cites ~$50M).
  • 2011-04-27 — Attachmate Corporation completes its merger with Novell (~$6.10/share), Novell becomes a wholly owned Attachmate Group subsidiary. Immediately prior to closing, Novell sold ~882 identified patents to CPTN Holdings LLC for $450M (consortium of Apple, EMC, Microsoft, Oracle) — press release via Micro Focus press room; DOJ consent decree modified the deal to protect open-source. This patent was not among the 882 — it continued to be held and encumbered by Novell afterward (see the 2011–2016 security-interest records below), which is consistent with CPTN taking a defined carve-out rather than the whole portfolio.
  • 2014-11 — Micro Focus International acquires The Attachmate Group, taking in Novell.
  • 2016-09-13 — the Novell, Inc. legal entity is renamed Micro Focus Software Inc. (recorded as a Change of Name).
  • Widely reported (not verified in the sources I reached this session): OpenText acquired Micro Focus in January 2023, which would make Micro Focus Software Inc. an OpenText subsidiary. Verify before relying on it.

---

Assignment timeline

All dates are the USPTO recording dates surfaced by Google's legal-event panel (the panel does not give execution dates for most of these). Where a conveyance description names a reel/frame, it is quoted.

• 2000-03-13 — Reel not exposed (Google panel omits reel/frame)

  • Conveyance: Assignment of Assignors' Interest
  • Assignor: Gregory Rakoshitz; Sanjeev Rao Putta; Aseem Vaid (individuals)
  • Assignee: UKIAH SOFTWARE, INC.
  • Correspondent: not available from sources reached
  • Context: inventors' original employment assignment to their employer — the root of title.

• 2001-06-07 — Reel not exposed

  • Conveyance: Assignment
  • Assignor: UKIAH SOFTWARE, INC.
  • Assignee: NOVELL, INC.
  • Correspondent: not available
  • Context: confirmatory transfer following Novell's June 1999 acquisition of Ukiah — internal corporate acquisition cleanup, not a third-party sale.

• 2011-05-12 — Reel not exposed

  • Conveyance: Grant of Patent Security Interest (first lien)
  • Assignor: NOVELL, INC.
  • Assignee: CREDIT SUISSE AG, Cayman Islands Branch
  • Correspondent: not available
  • Context: securitization — financing for the Attachmate merger that closed 2011-04-27.

• 2011-05-13 — Reel not exposed

  • Conveyance: Grant of Patent Security Interest (Second Lien)
  • Assignor: NOVELL, INC.
  • Assignee: CREDIT SUISSE AG, Cayman Islands Branch
  • Correspondent: not available
  • Context: securitization — second-lien companion to the prior day's grant.

• 2012-05-22 — Reel/Frame 026270/0001 and 027289/0727 (as named in the release) — Reel 026275/0018 and 027290/0983 (second lien)

  • Conveyance: Release of Security Interest in Patents — First Lien; and Release of Security Interest in Patents — Second Lien
  • Assignor: CREDIT SUISSE AG, as Collateral Agent
  • Assignee: NOVELL, INC.
  • Correspondent: not available
  • Context: internal reorg / refinancing — liens cleared and immediately re-granted (below).

• 2012-05-23 — Reel not exposed

  • Conveyance: Grant of Patent Security Interest — First Lien; and — Second Lien
  • Assignor: NOVELL, INC.
  • Assignee: CREDIT SUISSE AG, as Collateral Agent
  • Correspondent: not available
  • Context: securitization — refinancing; the day-after re-grant confirms the releases were a restructuring, not an ownership change.

• 2014-11-24 — Reel/Frame 028252/0216 and 028252/0316 (as named in the releases)

  • Conveyance: Release of Security Interest (two entries)
  • Assignor: CREDIT SUISSE AG
  • Assignee: NOVELL, INC.
  • Correspondent: not available
  • Context: securitization unwind — Credit Suisse collateral released as part of the Attachmate→Micro Focus transaction (Micro Focus completed the Attachmate Group acquisition 2014-11-05).

• 2015-05-13 — Reel not exposed

  • Conveyance: Security Interest
  • Assignors: ATTACHMATE CORPORATION; BORLAND SOFTWARE CORPORATION; MICRO FOCUS (US), INC.; NETIQ CORPORATION; NOVELL, INC.
  • Assignee: BANK OF AMERICA, N.A.
  • Correspondent: not available (the underlying instrument is indexed at plainsite.org as assignment id 7362657 — "Patent Assignment from Micro Focus (us), Inc.; Borland Software Corporation; Attachmate Corporation; Netiq Corporation; and Novell, Inc. to Bank of America, NA")
  • Context: securitization — replacement credit facility covering the whole Attachmate/Micro Focus group of entities.

• 2016-09-13 — Reel not exposed

  • Conveyance: Change of Name
  • Assignor: NOVELL, INC.
  • Assignee: MICRO FOCUS SOFTWARE INC.
  • Correspondent: not available
  • Context: change of name only — same legal entity; no transfer of ownership.

• 2017-05-02 — Reel not exposed

  • Conveyance: Notice of Succession of Agency
  • Assignors: BANK OF AMERICA, N.A., as Prior Agent
  • Assignee: JPMORGAN CHASE BANK, N.A., as Successor Agent
  • Correspondent: not available
  • Context: securitization — agent substitution only; no change in beneficial owner.

• 2017-10-11 — Reel not exposed

  • Conveyance: Security Interest
  • Assignors: ARCSIGHT, LLC; ATTACHMATE CORPORATION; BORLAND SOFTWARE CORPORATION; ENTIT SOFTWARE LLC; MICRO FOCUS (US), INC.; MICRO FOCUS SOFTWARE, INC.; NETIQ CORPORATION; SERENA SOFTWARE, INC.
  • Assignee: JPMORGAN CHASE BANK, N.A.
  • Correspondent: not available
  • Context: securitization — group-wide refinancing resubmitted under the new collateral agent.

• 2018-07-26 — Reel not exposed

  • Conveyance: Corrective Assignment (correcting a typo: application number 10/708,121 → 10/708,021, previously recorded at Reel 042388 Frame 0386)
  • Assignors: BANK OF AMERICA, N.A., as Prior Agent
  • Assignee: JPMORGAN CHASE BANK, N.A., as Successor Agent
  • Correspondent: not available
  • Context: recording correction only — clerical; affects a different application, not this patent.

• 2023-02-02 — Reel/Frame 035656/0251 and 044183/0718 (as named in the releases)

  • Conveyance: Release of Security Interest (two entries)
  • Assignor: JPMORGAN CHASE BANK, N.A.
  • Assignee(s): MICRO FOCUS SOFTWARE INC. (f/k/a Novell, Inc.) and affiliated Micro Focus/Borland/NetIQ/Attachmate entities
  • Correspondent: not available
  • Context: securitization unwind — liens released; timing tracks Micro Focus's acquisition by OpenText (which closed end-of-January 2023 per public reporting).

Post-issuance third-party ownership transfers: none. Every post-2001 record is either a security interest, a release of a security interest, an agency succession, a corrective filing, or a pure name change. The last true assignment of title in this chain is Ukiah → Novell, recorded 2001-06-07.

---

Timeline diagram

timeline
    title Ownership of US 6816903
    1999 : Application filed in December
         : Novell acquired Ukiah in June
    2000 : Inventors assign to Ukiah Software
    2001 : Ukiah assigns patent to Novell
    2011 : Novell Attachmate merger closes
         : Credit Suisse security interest
    2012 : Liens released and regranted
    2014 : Micro Focus buys Attachmate Group
         : Credit Suisse releases recorded
    2015 : Bank of America security interest
    2016 : Novell renamed Micro Focus Software
    2017 : JPMorgan becomes successor agent
    2019 : Expired for failure to pay fees
    2023 : Security interests released

---

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT. There is no assignment to any entity named "IP / Patents / Licensing / Holdings / Ventures." The only post-2001 "assignees of record" are (a) lenders taking security (Credit Suisse AG, Bank of America, JPMorgan Chase) and (b) the renamed operating entity itself (Micro Focus Software Inc., via the 2016-09-13 Change of Name). Security-interest grantees are collateral agents, not owners. No single-purpose LLC appears anywhere in the chain.

2. Known asserter in the chain — NOT PRESENT. I found no match against Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, or Spangenberg entities. The named parties (Ukiah, Novell, Attachmate, Micro Focus, Borland, NetIQ, Serena, ArcSight, Entit) are all operating software vendors or their lenders.

3. Repeat correspondent across the chain — UNCLEAR / NOT AVAILABLE. This is the one signal I cannot score: the Google legal-event panel omits the correspondent-of-record field entirely, and I could not reach the Assignment Center records that expose it. I decline to characterize it. Given that every link in this chain is a well-known operating company or a bulge-bracket lender — not an anonymous LLC — a single repeat filer here would read as ordinary in-house/outside corporate counsel, not an NPE handler. To close this out, pull the correspondent field for each reel/frame from assignmentcenter.uspto.gov.

4. Cascading transfers through chained LLCs in <24 months — NOT PRESENT. The dense cluster is 2011-05 through 2012-06, but it consists of lien grants and lien releases to the same lender, not changes of beneficial ownership. Similarly, the 2014-11-24 releases and 2017 agency succession are refinancing mechanics. There is no sequence of LLC-to-LLC assignments.

5. Pre-litigation transfer — NOT PRESENT. I found no infringement suit naming US 6,816,903 (district court, ITC, or PTAB), and re-confirm the prior section's finding of no CAFC 2026 activity. With no suit to point to, there is no transfer within 6 months of a complaint. Because the patent expired for failure to pay maintenance fees (anticipated 2019-12-03), assertion is now impossible.

6. Bankruptcy fire-sale — NOT PRESENT. Novell's 2011 disposition occurred in an out-of-court merger (Attachmate, ~$6.10/share) plus a negotiated pre-closing patent sale to CPTN Holdings — not a Chapter 7/11 proceeding. The 882-patent CPTN sale is a genuine portfolio monetization event, but this patent was not included in it (it remained with Novell and stayed under Novell/Attachmate security interests through 2016).

7. Privateering — NOT PRESENT. No evidence that Novell/Attachmate/Micro Focus transferred this patent to an NPE to assert against competitors. The only large-scale divestiture (CPTN, 2011) was a sale to operating-company buyers — Apple, EMC, Microsoft, Oracle — with DOJ-imposed open-source protections, and, again, 6816903 was not part of it.

8. Defensive aggregator — NOT PRESENT. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. The terminal ownership record is a Change of Name to Micro Focus Software Inc., an operating vendor.

---

Verdict

Insufficient data (with the substantive finding that no NPE hallmarks are present).

Justification. The recorded chain is complete and unremarkable: a root assignment from the three inventors to their employer Ukiah Software (2000-03-13), a confirmatory transfer to Novell (2001-06-07), and thereafter only security interests (Credit Suisse 2011-05-12/13 and 2012-05-23; Bank of America 2015-05-13; JPMorgan 2017-10-11), their releases (2012-05-22, 2014-11-24, 2023-02-02), an agency succession (2017-05-02), a corrective filing (2018-07-26), and a pure name change to Micro Focus Software Inc. (2016-09-13) — so there is no third-party ownership transfer after 2001-06-07, no shell LLC, no known asserter, and no litigation. I stop short of a clean "no NPE" call only because the primary source the task requires (Assignment Center reel/frame + correspondent of record) was unreachable in this session, leaving signal #3 unscored; verify at the USPTO Assignment Center: https://assignmentcenter.uspto.gov/ (search by patent number 6816903).

I'll research the prior-art citations for US 6,816,903. Let me run targeted searches against patent databases.

Let me dig deeper into the specific citation list on the patent record.

I need the actual "References Cited" list from the patent document. Let me try to retrieve it directly.

Retrieval status — read this first

I was unable to retrieve the enumerated "References Cited" list printed on the face of US 6,816,903. Two retrieval paths failed:

1. The authoritative full text supplied for this analysis ends within the "Summary of the Invention." It never reaches the front-page References Cited block or the claim set. (This is the same gap the prior section flagged for the claims — it applies equally to the citations.)
2. My web searches reached the Google Patents landing page for US6816903B1 but returned only the "Definitions" body text (which does not contain the citations table). The Patent Citations table itself was not captured.

Because of that, I cannot truthfully "look at each patent citation for 6816903" and enumerate them, and I will not fabricate a citation list. What follows separates (A) what I confirmed, from (B) the most relevant prior-art references I could actually ground from surrounding evidence — clearly labeled as candidate/relevant, not as the patent's own confirmed citations.

⚠️ Number-hygiene note carried forward from earlier sections: 6,816,903 ≠ 8,073,681 ≠ 8,363,681. Search engines repeatedly return the latter two. Neither is this patent. I exclude them.

---

A. Confirmed identification of the patent (brief; builds on prior sections)

The classification profile matters for prior-art scoping: the examiner treated the disclosure as sitting at the intersection of policy-based configuration management, flow classification/QoS, and network security policy (firewall).

---

B. What my searches did surface (each item labeled for what it actually is)

I want to be precise about direction of citation, because the search results mixed three very different things:

Net result for Section B: every '903-related entry I reached is either a family member (not prior art) or a forward citation (other patents citing '903). None is a confirmed backward citation of '903.

---

C. Most relevant prior art — candidate set (clearly labeled as NOT the confirmed citation list)

Since I could not read '903's own citation list, the following are the most relevant references in the field, dated to the '903 priority window, drawn from the surrounding evidence and the patent's own classification. These are candidates for the examiner's citation list — I could not confirm which, if any, appear on the face of '903. Treat every § 102 mapping here as provisional.

Each reference was surfaced in my searches (so the number/date/title are grounded), but its status vis-à-vis '903 specifically is unverified.

Forward-citation references (do NOT treat these as prior art to '903): US 6,829,781; US 8,484,321; US 7,839,781; US 7,171,457; US 8,271,980; plus the EPO EP 2 028 787 A1 report and the Korean KR 20030061794 family document surfaced earlier. These establish that '903 is itself cited as art — evidence of the field's trajectory, not of '903's novelty.

---

D. Provisional § 102 analysis (with the mandatory caveat)

Legal framework. Because both the earliest priority (1997-05-27) and the actual filing (1999-12-03) pre-date 2013-03-16, pre-AIA 35 U.S.C. §§ 102/103 govern. The controlling date per claim family determines which § 102 subsection bites:

• If a claim is entitled to the 1997-05-27 priority → § 102(b) art must pre-date 1996-05-27; § 102(a) art must pre-date the invention.
• If a claim is entitled only to the 1999-12-03 filing date (e.g., new matter added in the CIP) → § 102(b) art must pre-date 1998-12-03; § 102(e) art is by others filed before the invention.

Claim-mapping caveat (critical, carried forward). The claim set for '903 remains unconfirmed (prior sections flagged this and I could not close it). The only external anchor is the EPO search report treating claims 1–6 as the relevant range. I therefore map to the three inferred claim families from the prior summary — (1) method with firewall + distributed tool, (2) system with real-time bandwidth profiling GUI, (3) program-code bandwidth profiling tool — and I explicitly do not assert a specific claim number anticipates.

No reference here is confirmed as an anticipating § 102 reference. I am not asserting that any single reference anticipates any specific claim; I am identifying candidates that a search report would be expected to list, with the theory under which each would be considered.

---

E. Caveats and verification steps

1. The enumerated citation list was not retrievable in this session. I will not present a fabricated list. To obtain the authoritative "References Cited," pull from any of:
   • USPTO PatentCenter → Patent No. 6816903 → References Cited / full document: https://patentcenter.uspto.gov
   • Google Patents → US6816903B1 → the "Patent Citations" (backward) panel (distinct from "Cited By"): https://patents.google.com/patent/US6816903B1/en
   • FreePatentsOnline and Espacenet → "Cited documents" view.
2. Do not confuse direction. The lists I could reach were dominated by forward citations (later patents citing '903) and family members. The task requires backward citations (art relied on during '903's prosecution). Confirm direction before citing anything from Section B.
3. Number hygiene. Re-confirm the number is exactly 6,816,903 and not 8,073,681 or 8,363,681.
4. Claim scope remains open. Until the official claim set is pulled, any § 102 mapping (including mine) is provisional. The EPO report's "claims 1–6" is a range indicator, not a construction.
5. Strategic context (from prior sections, unchanged): '903 is expired — fee related (anticipated 2019-12-03). For any invalidity purpose this makes prior-art mapping largely academic; the operative defense is expiration + the § 286 six-year lookback, not § 102. Prior-art analysis matters here only for completeness or for a parallel/related family member.

One-line bottom line: I confirmed the patent's identity and its classification profile, but could not retrieve US 6,816,903's own "References Cited" list, so I did not enumerate its citations; the items my searches actually returned are family members or forward citations, and the candidate prior art in Section C is offered as unverified, relevant references only — to be confirmed against PatentCenter before reliance.

I'll research the prior art cited on this patent's face and in related proceedings before building § 103 combinations.

Let me retrieve the cited prior-art references on the patent's face and the sibling patents.

Obviousness Analysis — U.S. Patent 6,816,903 B1 (35 U.S.C. § 103)

Prepared: 2026-04-26 (see date-conflict flag below)
Analyst note on sourcing: I am a technical analyst, not counsel. This is a technical obviousness assessment, not a legal opinion or a validity opinion.

---

0. Read this first — three gating caveats

0.1 — The "Prior Art section of this page" was not supplied to me. The task instructs me to "use the results from the Prior Art section of this page," but the previously generated sections provided in my input are only: (i) Patent summary, (ii) Litigation summary, (iii) PTAB challenges, (iv) Proceedings overview, (v) Assignment history. There is no Prior Art section in what I received. I therefore could not consume it, and I will not pretend to have done so. Instead I have built a prior-art inventory from what is actually recoverable and verifiable from the record: (a) the patent's own specification (which contains several express admissions and in-line citations), (b) the face of the same-family parent US 6,578,077, whose "References Cited" list I retrieved, (c) EPO/foreign search reports that date and categorise the field's art, and (d) field knowledge, which I have labelled by confidence in every instance. If a genuine Prior Art section exists and differs from the inventory below, the combinations must be re-run against it.

0.2 — Contradiction flags (per operating rule, stated explicitly, not auto-corrected):

0.3 — What I still cannot confirm. The verbatim claim set and the patent's own "References Cited" list were not retrievable in this session. All claim-element mapping below is inference from the abstract and specification, exactly as flagged in the earlier section. Any conclusion here is provisional on the official claim text at USPTO PatentCenter.

---

1. Governing law and the person having ordinary skill in the art

1.1 Statute. The application was filed 1999-12-03 and issued 2004-11-09. Its effective filing date is therefore before 2013-03-16, so pre-AIA 35 U.S.C. §§ 102 and 103 govern. Consequences that matter:

• Pre-AIA § 102(e) applies to U.S. patents and published applications as of their U.S. filing date (no "effective filing date" reformulation), and pre-AIA § 103(c) (common ownership) can disqualify § 102(e)/(f)/(g)-only art from being used in a § 103 combination — but not from § 102 anticipation. This is decisive for the best references in this family (§ 7 below).
• Pre-AIA § 102(b) requires publication more than one year before filing — i.e., before 1998-12-03 for any claim not entitled to the 1997 priority.
• KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007) applies: the TSM test is not the sole test; a combination is obvious where (i) the improvement is a predictable use of prior-art elements according to their established functions, (ii) a known technique is used to improve a similar device in the same way, (iii) a design need or market pressure exists with a finite number of identified, predictable solutions, or (iv) the reference itself teaches away. MPEP 2143 supplies the articulation template.

1.2 POSITA (proposed definition). As of mid-1997 to December 1999, a POSITA in this art would hold a B.S. in computer science, computer engineering, or electrical engineering (or equivalent) plus 2–4 years designing or administering enterprise IP networks, and would be familiar with, as of the relevant dates:

• TCP/IP, UDP, HTTP/FTP/SMTP/POP3/Telnet/DNS; SNMP (RFC 1157, May 1990) and RMON (RFC 1757, Feb 1995) and RMON2 (RFC 2021, Jan 1997) manager/agent architecture;
• Integrated Services (RFC 1633, June 1994), RSVP v1 (RFC 2205, Sept 1997), the controlled-load and guaranteed-service specifications (RFC 2211 / RFC 2212, Sept 1997), and Differentiated Services (RFC 2474 / RFC 2475, Dec 1998) with assured/expedited forwarding PHBs (RFC 2597 / RFC 2598, June 1999);
• Queuing and rate-control primitives in shipping routers: weighted fair queuing (WFQ), priority queuing, custom queuing, and committed access rate (CAR) (Cisco IOS releases from the mid-1990s);
• Firewall/gateway rule bases matching on source address, destination address, port/service, and time-of-day (e.g., Check Point FireWall-1's rule base and time objects);
• Directory services: X.500/LDAP (RFC 1959 / RFC 1960, June 1996) and Novell NDS;
• The Directory-Enabled Networks (DEN) specification and the DMTF Common Information Model work (Cisco/Microsoft, 1998), and the IETF RAP working group's policy decision point / policy enforcement point model as it stood in 1998–1999 (the RFCs that formalised it, RFC 2748/2749/2750/2753, are January 2000 and are therefore not prior art to this patent on their face — see § 6.2).

1.3 Field of the art. All references below are in the single field of network traffic measurement and control (plus the directly adjacent field of directory services/DEN as a policy repository). This is not a non-analogous-art case; the In re Bigio / In re Klein "field of the invention" and "reasonably pertinent to the problem" tests are satisfied on their face for every combination proposed.

---

2. Prior-art inventory (with per-item confidence)

Confidence key: [V] verified in this session's retrievals · [F] same-family, number verified · [K] field knowledge, number not verified here — verify before filing.

2.1 The patent's own admissions (these are prior art to the patent on its own face)

2.2 Same-family references (the § 102(e) cluster)

2.3 Third-party references cited on the '077 face [V for the list; K for each item's content]

US 5,365,514 (Hershey et al., 11/1994) · US 5,446,874 (Waclawsky et al., 8/1995) · US 5,493,689 (Waclawsky et al., 2/1996) · US 5,519,689 (Kim, 5/1996) · US 5,521,907 (Ennis, Jr. et al., 5/1996) · US 5,583,792 (Li et al., 12/1996) · US 5,615,323 (Engel et al., 3/1997) · US 5,664,105 (Keisling et al., 9/1997) · US 5,867,483 (Ennis, Jr. et al., 2/1999) · US 6,097,722 (Graham et al., 8/2000) · EP 0 460 843 A2 (11/1991) · Gaspoz, J.P., "Applying an object-oriented method to design a VPN bandwidth management system," Annales des Télécommunications (Paris), 1995 · Jander, M., "Beyond RMON: Making Sense of Remote Data," Data Communications, June 1, 1992, pp. 51–52, vol. 21, no. 9 · EPO Supplementary Search Report for EP 98 96 6473 (Oct. 31, 2001) · ISR for PCT/US98/27396 (May 26, 1999).

Analytical weight: Jander (1992, "Beyond RMON") and Gaspoz (1995) together establish that before the priority date, the art already combined (i) per-flow/per-conversation bandwidth accounting collected by remote monitoring agents with (ii) a management-station presentation layer for bandwidth management. Those are precisely the two halves of the '903 profiling claims. Ennis (5,521,907 and its 2/1999 successor 5,867,483) is the network-traffic monitoring/analysis lineage. Waclawsky (5,446,874 and 5,493,689) is the IBM per-flow congestion/bandwidth-management lineage. These are the natural base references for any § 103 attack on the profiling and bandwidth-management claims.

2.4 Third-party references cited against the same field by examiners [V]

2.5 Post-dating references (usable only as context, not as § 102/§ 103 art) [V]

RFC 2750 (Herzog, "RSVP Extensions for Policy Control"), RFC 2753 (Yavatkar et al., "A Framework for Policy-based Admission Control") and RFC 2749 (Herzog et al., "COPS usage for RSVP") are all dated 1 January 2000 on the search report reproduced in the record. All three post-date the 1999-12-03 filing and are not prior art. Their working-group drafts circulated in 1998–1999 and may be citable, but I have not verified draft dates and will not assert them.

Market/product art [K — verify each]: Packeteer PacketShaper (shipping 1997); Allot NetEnforcer (1996–97); Xedia Access Point; Check Point FireWall-1 rule bases; Cisco IOS CAR/WFQ/priority/custom queuing; HP OpenView Network Node Manager; NetScout Manager and RMON/RMON2 probes; Concord Network Health; Cabletron Spectrum; Microsoft Windows NT Network Monitor; Novell ManageWise and NDS; Ukiah NetRoad TrafficWare (1997). I flag these as to-be-corroborated with dated documentation (product manuals, press releases, trade press). They are useful as motivation and background evidence even where they are not formal § 102 art.

---

3. Claim families analysed

Because the verbatim claim set remains unrecovered, I analyse against the three families the earlier section inferred, expressly narrowing them in light of the six-claim evidence:

• Family I — Method (inferred): provide a network of computers with a firewall server and a distributed traffic management tool coupled to the firewall server; implement monitoring/profiling of incoming and outgoing information from an information source.
• Family II — System (inferred): a computer network system with a real-time bandwidth profiling tool having a GUI with a first portion displaying a graphical chart of information flow from a source and a second portion displaying text describing the flow, the combination describing the profiled information, plus an output identifying the source from among firewall/server/LAN/WAN/client.
• Family III — Program product (inferred): code to measure a data rate of a flow; code to categorise the data rate into one of a plurality of traffic classes; code to output a graphical representation of the data rate; code to output a text representation of the traffic class; and (per the '903 abstract/summary but not per the '077 summary) code to display the origin of the flow.

I also analyse two unclaimed-but-possible subject matters that dominate the specification and may well be in dependent claims: (IV) rule-based traffic classes and policies (FIG. 8; source/destination/service/file-type/URL/time conditions; guarantees, limits, priority, admission control) and (V) the distributed/directory-enabled policy architecture (DPMA; FAME, URS, EPM, EPS/ETS, EQOS Agent, DARE; policy enforcement points/proxies — FIGS. 16–19).

---

4. The § 103 combinations

For each combination I give the statutory rationale label (the KSR/MPEP 2143 hook), the element mapping, and the motivation.

---

Combination 1 — Family III (program product): measuring a data rate, classifying it, and charting it

References: A1 (Windows NT Performance Monitor — admitted prior art) + R11/R7 (Ennis, Jr. et al., US 5,521,907 and US 5,867,483 — network traffic monitoring/analysis, per F1's citation list) + A4 (the admitted traffic taxonomy) + R15 Jander ("Beyond RMON," 1992).

Rationale: KSR rationale (A) — "predictable use of prior-art elements according to their established functions," and (D) — "obvious to try from a finite number of identified, predictable solutions."

Mapping:

• "measure a data rate for a flow of information" → RMON/RMON2 counters (etherStatsOctets, host and matrix tables) measure octets/rate per conversation; Ennis-type monitoring systems compute rate statistics per monitored segment/entity.
• "categorize the data rate … based upon at least one of a plurality of traffic classes" → RMON/RMON2 protocol-directory classification (per-protocol, per-host, per-matrix statistics) and the admitted taxonomy at A4 (DNS/PING/Telnet, FTP, HTTP, mail/news, Push). The patent's own "traffic class" content — source/destination/service/file type/URL/time — is a superset of standard RMON/SANM classification fields.
• "output a visual representation of the data rate in graphical form" + "text representation of the traffic class" → A1 precisely: the Performance Monitor's chart pane plus its legend, driven by a counter selected by Computer/Object/Counter/Instance. The specification's own FIGS. 12–15 are screenshots of this admitted tool.
• "display the origin of the flow" → the "Instance" and "Computer" fields of the admitted tool, and the host/matrix tables of RMON.

Motivation (POSITA-level, contemporaneous): an NT network administrator confronted with Internet-access congestion already had (i) RMON/RMON2 agents producing per-conversation and per-protocol counters, and (ii) the Performance Monitor charting shell that could plot any exposed counter, plus network-monitor list views. Wiring RMON-classified counters into the Performance Monitor counter interface requires no change to the display technology whatsoever — the patentee concedes as much. The only asserted novelty is the identity of the data plotted. KSR holds that substituting one known data source for another in a known display, to obtain the display's known benefit (visual trending), is obvious. There is no teaching away: Jander's 1992 complaint that RMON alone "doesn't make sense of remote data" is a call to add presentation/analysis on top of RMON agents — i.e., it supplies the very motivation.

Strength: High for any claim whose GUI limitations are as abstract as "graphical chart in a first portion; text in a second portion." This is the combination I would lead with, because A1 is the patentee's own admission and therefore cannot be disputed as to what it discloses.

---

Combination 2 — Families II/III (profiling tool & system): per-service / per-server / per-client profiling with a two-portion display

References: F1 US 6,578,077 or F2 US 6,078,953 (base — same disclosure) + A1 (chart + legend) + R15 Jander / R14 Gaspoz (per-flow bandwidth accounting on a management station) + A2 (Ukiah TrafficWare as an on-sale/known product).

Rationale: same as Combination 1, plus KSR rationale (B) — "known technique … used to improve a similar device in the same way."

Mapping: the '077/'953 disclosure supplies the cumulative per-service, per-server and per-client statistics tables (Kb transferred, connect response time with min/max, request response time, session count, retry %, aborts %, bottleneck speed, retransmit %, last-active time), the FAST measurement module, the FAIR control module, the policy engine, and the deployment diagrams at ISP / web-hosting / campus / multi-site gateways. A1 supplies the chart-plus-legend rendering. Joining a set of counters to a counter-plotting tool is the definition of a predictable combination.

The statutory problem — and why this combination must be pleaded carefully: see § 7.1. F1/F2 are almost certainly § 102(e)-only art, and pre-AIA § 103(c) common-ownership may knock them out of a § 103 combination even though they remain available for § 102 anticipation. Practice note: plead this combination in the alternative — as § 102(e) anticipation by F1/F2 standing alone, and as § 103 over F1/F2 + A1, with an express § 103(c) analysis of ownership at the time of invention.

---

Combination 3 — Family I (method at a firewall/gateway) and family IV (rule-based policy engine)

References: P1 Ramanujan (LCN '98) + R4/R5 Waclawsky (US 5,446,874 / US 5,493,689) + A1/A2 (firewall/gateway platform, incl. the patentee's own TrafficWare firewall server) + A4 (admitted taxonomy of applications and QoS metrics) + RFC 1633 / RFC 2205 / RFC 2211 / RFC 2212 / RFC 2474 / RFC 2475 / RFC 2597 / RFC 2598 [K on exact dates] for the QoS mechanisms the policies select.

Rationale: KSR rationale (C) — "design need / market pressure, finite number of identified, predictable solutions" — plus (A).

Mapping:

• "policy-driven QoS control tool" → P1 expressly discloses an automated resource management tool for policy-driven QoS control. On the EPO's own citation, it is a "Y" reference against the independent claims of a closely analogous claim set. Ramanujan teaches taking higher-level policy and mapping it to network QoS resource parameters, with monitoring feedback.
• "monitor incoming and outgoing information" → R4/R5 (Waclawsky) teach per-flow/per-conversation measurement and administration of network bandwidth in packet networks, bidirectionally, on a link.
• "firewall server … traffic management tool coupled to the firewall server" → A1/A2. The specification itself states the tool "can be stand-alone at the WAN access point (e.g., behind the Internet access router or behind a firewall), with a conventional firewall or with an NT based proxy/caching server." The selection of the firewall/gateway as the deployment point is an admitted, art-recognised design choice.
• "traffic classes … policies (guarantees, limits, priority, admission control)" → the IntServ/RSVP/DiffServ mechanism set combined with the admitted taxonomy; admission control as such was a long-published ATM/IntServ concept.

Motivation: (i) The bottleneck/observation argument. The firewall is where all inbound and outbound traffic crosses; a POSITA seeking complete traffic visibility and complete enforcement capability locates both there, because measuring anywhere else yields partial data and enforcing anywhere else requires touching client, server and router configurations — which the specification itself identifies as a drawback of the prior approach ("they require both the sender and receiver to both agree on using the same hardware and/or software"). That expressed drawback is itself evidence that the single-chokepoint solution was the recognised, desirable design direction, not an invention. (ii) The unified-policy argument. The patent's own policy engine holds security policy 201 and traffic policy 202 in one module; firewalls already had mature rule engines matching source, destination, service/port and time-of-day, so reusing that engine to select a QoS action instead of a permit/deny action is a substitution of one known action for another with a predictable result. (iii) The P1 argument. Ramanujan supplies the specific missing teaching — a tool that automates policy → QoS — so the combination is a two-reference, same-field, no-teaching-away combination.

Strength: Moderate-to-high, and it is the only family of combinations that does not depend on the common-owned references, which is why it is the fallback if § 103(c) bites (§ 7.1).

---

Combination 4 — Family V (distributed policy management): agents, a policy server, and directory-stored policy

References: RFC 1157 (SNMP, 1990) + RFC 1757 (RMON, 2/1995) + RFC 2021 (RMON2, 1/1997) [K on exact dates] as the manager/agent + distributed probe architecture + the 1998 Directory-Enabled Networks (DEN) specification and DMTF CIM work (Cisco/Microsoft) [K — verify the exact published DEN date] + LDAP RFC 1959/1960 (June 1996) [K on exact dates] + P1 Ramanujan + A4/A1.

Rationale: KSR rationale (A) and (B).

Mapping:

• "distributed … over the network by way of one or more agents" → SNMP/RMON's existing manager–agent/probe split is the archetype. The '903 distributed architecture (FIGS. 16–19: workgroup/server/backbone switches, data-centre and WAN routers, QoS agents in the voice gateway, application and video servers, and at policy services) is the SNMP/RMON deployment topology with QoS policy objects instead of MIB objects.
• "policy decision engine / policy enforcement point" → the DEN/1998–99 RAP draft model [K on exact dates], i.e., an external decision point that push-configures enforcement agents. Note that the RFCs that canonise this vocabulary are January 2000 and are NOT prior art (§ 6.2) — so the practitioner must use the 1998–99 drafts and the DEN specification, not RFC 2748/2749/2750/2753.
• "meta-directory / directory-enabled" and "traffic classes can incorporate users and groups" → DEN's express teaching: store policy objects in the directory, resolve directory objects (users, groups, organisational units) to device-level configuration, so that policies do not have to be maintained against volatile IP addresses.
• "leverag[ing] existing management directories" → LDAP/NDS.

Motivation: The strongest available motivation comes from the art itself and is reinforced by the patent's own framing. The patent's stated advantage is that it "provides a single point or a single region to manage telecommunication traffic including directory services and bandwidth management," and its DPMA/EPM narrative criticises the need to "duplicate yet another data store." That is a restatement of DEN's stated purpose, published in 1998: the motivation to stop duplicating user data and to key policy on directory identity rather than IP address was express in the prior art. Under KSR rationale (A), taking the known DEN approach (policy objects in a directory) and applying it to the known policy-driven-QoS tool of Ramanujan (P1) produces a predictable improvement (policies follow the user through DHCP churn) with no asserted unexpected result.

Strength: Moderate. Its vulnerability is date-proof: the two references it needs most (DEN and the RAP drafts) sit close to the 1999-12-03 filing line, and I have not verified their publication dates. Verification item #1.

---

Combination 5 — Family IV (rule-based control flow, FIG. 8): classify → measure → timestamp → test conditions → apply policy

References: Firewall/policy-routing rule engines of the prior art [K — e.g., Check Point FireWall-1 rule bases and time objects; Cisco extended ACLs with time-range; policy routing] + R15 Jander (remote per-flow data collection) + P1 Ramanujan + A1 (counter-based triggering) + RFC 1757's alarm and event groups [K].

Rationale: KSR rationale (A) and (C).

Mapping: the FIG. 8 flow — start → classify flow into one of a plurality of predetermined classes → measure parameters for the class → time-stamp the parameters → determine whether to apply a policy based on the class, the time, and the link state → apply policy (bandwidth guarantee / limit / priority / admission control) or loop back to measuring — is a conditional rule evaluation against a classified flow. Firewall rule bases already performed exactly this evaluation, in this order (parse packet → match against a class defined by source/destination/service/time → take action), and RMON alarm groups already performed threshold-and-event evaluation on measured counters. The added step is that the "action" is a QoS action.

Motivation: (i) The patentee's own engine design — security policy 201 and traffic policy 202 dispatched by one policy engine 231 — shows that the inventors regarded "the same rule engine, a different action" as the natural architecture; a POSITA would agree. (ii) Time-based rules were conventional in the security art (firewall time objects), so importing a time condition into a QoS rule adds nothing inventive. (iii) Event/threshold triggering was conventional in the monitoring art (RMON alarm/event groups), so the "apply policy when measured state crosses a threshold" step is a known technique applied to a known data stream. (iv) The patent's own claimed advantage — "policy validation that prevents users from defining any contradictory or ambiguous rules" — is a well-known property of firewall rule-base compilers, i.e., of the very rule engines the POSITA would reuse.

Strength: Moderate-to-high against any claim that recites the FIG. 8 decision sequence as such.

---

Combination 6 — Family V's event-driven / "self-healing" aspect

References: RMON alarm and event groups (RFC 1757) [K] + R11 Ennis US 5,867,483 [K on content] + enterprise event correlation/management platforms of the era (HP OpenView NNM, Cabletron Spectrum, Concord Network Health) [K] + P1 Ramanujan.

Rationale: KSR rationale (A).

Mapping/motivation: the specification's "meta-policy service … distributes policies to intelligent agents, maintains network state information, correlates dynamic events, and … take[s] corrective action in accordance with pre-determined network policies … dynamically re-allocating bandwidth based on network response time" is the SNMP trap + RMON alarm → automated corrective action paradigm, which was standard enterprise-management practice by 1997. The event-driven policy invocation adds a QoS action to an existing alarm-action mechanism. Also applicable: the interactive GUI ("alarm at what threshold, and in what form e.g. email notification, pager message, SNMP trap, log entry") is the standard notification-configuration UI of every management platform of the period.

Strength: Moderate, and only relevant if a dependent claim actually recites event-triggered policy.

---

5. Single-reference (anticipation / near-anticipation) observations

These are not § 103 combinations but they bear on the same question and should not be omitted:

1. P1 Ramanujan (LCN '98), if § 102(b). If any '903 claim is not entitled to the 1997 priority, Ramanujan is a § 102(b) printed publication more than one year before the 1999-12-03 filing. The EPO treated it as an inventive-step-defeating "Y" reference against independent claims of an analogous claim set. That suggests it is at minimum a single-reference § 103 base against an independent claim, and possibly a § 102 reference to the extent it discloses a policy-driven QoS management tool with monitoring.
2. The Windows NT Performance Monitor (A1) for the GUI-only claims. If a Family II or III claim consists of "first portion chart; second portion text; identify the source," A1 alone discloses every structural element, with the only difference being the identity of the counters. That is a § 102-vs-§ 103 boundary worth briefing — the patent arguably claims the display of information rather than a technical improvement, and the display apparatus is verbatim admitted prior art.
3. F1 / F2 for the same subject matter. Because the '903 specification is substantially the '077/'953 specification, whichever of its claims read on the '077/'953 disclosure are squarely anticipated under pre-AIA § 102(e), subject only to the effective-filing-date determination (§ 0.2) and subject to "by another" (satisfied: R+P vs R+P+V). This is likely the fastest invalidity path in the whole family if the § 102(e) date holds.

---

6. Statutory limits that will defeat otherwise-good references — do not skip this

6.1 The § 103(c) common-ownership problem (the single biggest constraint on the analysis).

F1 (US 6,578,077), F2 (US 6,078,953) and the rest of the Ukiah/Novell family were commonly owned with the '903 application at the time the invention was made (inventors under obligation to Ukiah Software, and Novell the ultimate assignee). For applications in this vintage, pre-AIA § 103(c) provides that subject matter that qualifies as prior art only under § 102(e), (f) or (g) shall not preclude patentability under § 103 where the subject matter and the claimed invention were, at the time the invention was made, owned by the same person or subject to an obligation of assignment to the same person. Consequences:

• F1/F2 remain fully available for § 102 anticipation (no common-ownership exception attaches to § 102).
• F1/F2 may be unavailable as § 103 combination art. Combination 2 above must therefore be pleaded in the alternative and the ownership history — including whether anything was ever transferred out of common ownership before the operative invention date — must be documented.
• The exception does not extend to § 102(a)/(b) art. If any family member published (e.g., as a foreign counterpart, an issued patent more than a year before filing, or a product/white-paper disclosure) it becomes § 102(a)/(b) art and § 103(c) does not help the patentee. This is exactly why the Ukiah NetRoad TrafficWare 1997–98 product/press exposure (A2) and any Ukiah white papers should be dated and evaluated first — they are the one family-adjacent source that would escape § 103(c).

6.2 The January-2000 RFC trap. RFC 2750, RFC 2753 and RFC 2749 — the three references that map most cleanly onto "policy-based admission control" and "policy control of RSVP" — are dated 1 January 2000 in the record and post-date the 1999-12-03 filing. They are not prior art. Any obviousness theory that leans on them is void. Use the 1998–99 RAP working-group Internet-Drafts instead, and verify their dates and public accessibility (Internet-Drafts are printed-publication candidates only if publicly accessible and sufficiently disseminated — this is contestable).

6.3 The priority-date fork. The whole case forks at the effective filing date:

• If the claims are entitled to 1997-05-27 (provisional 60/047,752) or 1997-12-29 ('077), then P1 Ramanujan (Oct 1998) is not prior art at all, and Combinations 1–3 and 5 all collapse on their primary third-party reference.
• If the claims are entitled only to 1999-12-03, Ramanujan is § 102(b) art and the Combinations hold.
  Because '903 is a CIP, the correct answer is claim-by-claim: each claim gets the earliest date for which the corresponding subject matter is supported under § 112 in the earlier application(s). This is the first thing to litigate or to verify, and I cannot resolve it from the record.

6.4 The '903 cross-reference oddity. The '903 cross-reference block claims priority from '077 and from US 6,502,131 (filed Dec 4, 1998) and from provisional 60/110,976 (Dec 4, 1998) — i.e., three priority sources. Multiple priority claims of this kind invite the § 112 support question for each claim separately.

---

7. Secondary considerations (objective indicia)

I can identify no objective evidence of non-obviousness on the record reached:

• No unexpected results are asserted anywhere in the specification; the stated advantages are the ordinary, expected consequences of single-point policy enforcement ("fair sharing," "congestion avoidance," "more reliable and faster service for valued applications"). Those are the predicted results of the combination, not evidence against it.
• No long-felt unmet need evidenced as such. The patent argues that link upgrades are inadequate, but that is a motivation in the prior art, not a secondary consideration — and KSR treats expressed design need as weighing for obviousness.
• Commercial success — Ukiah's NetRoad TrafficWare (1997) and its ZENworks for Networks successor — is not linked by any nexus to the claimed subject matter in the record. Importantly, the product predates the '903 filing (A2), which undercuts both nexus and any reading of the product as evidence of the claims' contribution.
• No industry praise, licensing, or copying evidence surfaced; and there is no litigation and no PTAB record in which such evidence was ever tested (per the prior sections of this document).
• Caution on the reverse inference: as the earlier section correctly held, the absence of IPRs here is consistent with a patent that was never worth attacking, not with a patent that resisted attack. It is not evidence of non-obviousness, and it should not be argued as such.

---

8. Collateral point worth flagging (not § 103)

Obviousness-type double patenting. '903 (issued 2004-11-09) and '077 (issued 2003-06-10) share a specification, share inventors, share a common owner (Novell), and litigate the same subject matter across a CIP/continuation relationship. If any '903 claim is not patentably distinct from a '077 claim, ODP is available as a separate invalidity challenge, independent of the prior-art combinations above. Caveats: (i) ODP is defeated if a terminal disclaimer was filed — the file wrapper is decisive and I have not seen it; (ii) ODP also requires common ownership; (iii) ODP requires the patents to be commonly owned at the time of enforcement for the safe-harbour to apply. Verify the '903 and '077 file wrappers at PatentCenter before investing in this theory.

---

9. Bottom line

Ranked, with the reason each ranks where it does:

The one sentence to carry forward: the '903 GUI/profiling subject matter appears very likely obvious, largely because the patentee admitted that the charting shell, the counter-selection dialogs, the sortable tables and the notification options are stock Windows NT Performance Monitor, and the only asserted contribution is which counters feed them; whereas the directory-enabled distributed policy-management subject matter is the harder case and depends entirely on (a) the effective filing date fork and (b) the DEN/RAP draft dates, neither of which I could resolve from the record available.

---

10. Verification checklist (do these before relying on any combination)

1. Pull the verbatim claim set from USPTO PatentCenter for 6,816,903. Everything above is family-level inference until this is done. Confirm whether the set is in fact six claims (per the EPO's "claims 1–6" citation) and how many are independent.
2. Determine the effective filing date claim-by-claim from the file wrapper and the priority documents: provisional 60/047,752 (1997-05-27), provisional 60/067,857 (1997-12-05), application 08/999,517 → US 6,578,077 (1997-12-29 vs. the '903 text's "Dec. 12, 1997"), provisional 60/110,976 (1998-12-04), and US 6,502,131 (1998-12-04). Resolve the Dec. 12 / Dec. 29 discrepancy.
3. Date and authenticate P1 (Ramanujan, LCN '98, 11–14 Oct 1998) — obtain the paper and its copyright/publication page. It is the single most useful third-party reference in the record if the priority date fork breaks toward 1999-12-03.
4. Verify the DEN specification (Cisco/Microsoft, 1998) publication date and the 1998–99 IETF RAP working-group Internet-Draft dates and public accessibility.
5. Run the pre-AIA § 103(c) ownership analysis for the Ukiah/Novell family as of the invention date, and check both file wrappers for § 103(c) statements and terminal disclaimers (also relevant to the ODP theory in § 8).
6. Confirm F2's identity — number US 6,078,953, its title, filing date and issue date — since I retrieved its text but not its bibliographic data. Do the same for US 6,047,322, US 6,137,777, and US 6,502,131.
7. Obtain the '903's own "References Cited" list (the expired-record copy I could reach does not render it) — this is the missing "Prior Art section" of the analysis and directly controls whether any of the above was already before the examiner.
8. Date the Ukiah NetRoad TrafficWare 1997–98 publicity and any white papers — this is the one family-adjacent source that could qualify as § 102(a)/(b) art and therefore escape the § 103(c) common-ownership disqualification.

If the true Prior Art section of this page exists and contains references I have not inventoried here, supply it and I will re-run § 4 against it and mark exactly which combinations survive.

---

Links cited: patent record — https://patents.google.com/patent/[US6816903B1](/patent/US6816903B1)/en · parent US 6,578,077 full text — https://patentimages.storage.googleapis.com/d9/a1/5c/d3dee072f6d2ae/US6578077.pdf · US 6,578,077 as Samsung IPR Exhibit 1046 (IPR2024-01397) — https://www.docketalarm.com/cases/PTAB/IPR2024-01397/Samsung_Electronics_Co._Ltd/docs/09-09-2024-Petitioner/Exhibit-1046-US_Patent_No_6,578,077_Rakoshitz.pdf · EPO search report on EP 1 357 698 A1 (cites Ramanujan as "Y" against claims 1, 5, 9; cites WO 00/35130 A, EP 1 047 226 A, and RFC 2750/2753/2749 as "A"/"A,D") — http://data.epo.org/publication-server/rest/v1.2/patents/EP1357698NWA1/document.pdf · EPO search report on EP 2 028 787 A1 (cites US 6,816,903 against claims 1–6, Figs. 9–11, 13) — https://patentimages.storage.googleapis.com/a9/1c/8c/de4a6a68ae1b88/EP2028787A1.pdf · EPO search report on EP 1 892 894 A1 (cites US 6,816,903 at Figs. 1, 6, 16; col. 2, 3, 5, 6, 9, 11, 17) — https://patentimages.storage.googleapis.com/00/a7/a6/435099fa3c9ad0/EP1892894A1.pdf · EP 2 140 610 B1 description citing "US 6816903 B1, Rakoshitz" — https://patentimages.storage.googleapis.com/85/75/1c/64141bc0e7ca0f/EP2140610B1.pdf · PubChem patent record (10 citations / 11 cited-by) — https://pubchem.ncbi.nlm.nih.gov/patent/US-6816903-B1 · USPTO PatentCenter — https://patentcenter.uspto.gov · USPTO Assignment Center — https://assignmentcenter.uspto.gov/