US 6119235

I'll search for current litigation/assignment records on this patent number, then summarize against the authoritative text provided.

US 6,119,235 — Search Results & Summary

Search scope and confidence note

I searched for this specific number. What I found (and did not find):

• USPTO/CAFC litigation: I found no district-court docket, PTAB proceeding, or CAFC appeal involving US 6,119,235. In particular, no CAFC 2026 docket entry referencing this patent surfaced. I cannot treat this as a definitive "no litigation ever" conclusion — my searches were web-based, not a direct PACER/PTAB API query, and the patent is long expired (2017), so any 1990s–2000s enforcement activity may simply not be well indexed online. Treat the litigation finding as "none located," not "none exists."
• Number-collision warning: Searches for "6119235" also return JP Patent No. 6119235 (JP6119235B2), a 2017 Ricoh imaging-control patent for multi-optical-system cameras. That is an unrelated Japanese patent that merely shares the same digits. It is not the target and I have excluded it. Similarly, citations of "US 6119235 A" appearing in CN1685323B and CA2424680A1 are third-party citations to the target patent, not the patent itself.

Bibliographic data (per the authoritative full text provided)

Assignment chain (as recorded): Ukiah Software, Inc. (original) → Novell, Inc. (2001-06-20) → CPTN Holdings, LLC (2011-10-06) → EMC Corporation (2011-10-02 record) → EMC IP Holding Company LLC (2016-09-29). The Google Patents "current assignee" field shows EMC Corp, with later Dell/EMC collateral and release records (2016–2022). Because the patent expired in 2017, the "current assignee" designation is of historical rather than enforcement significance.

Abstract

A method for managing quality of service in a firewall server, the firewall server coupling a data source to a data receiver, includes the steps of estimating a bit rate over a round-trip-time between the data source and the data receiver, receiving a receive acknowledgment signal from the data receiver, thereafter delaying transmission of a receive acknowledgment signal when the bit rate is greater than a bit rate limit, and transmitting the receive acknowledgment signal to the data source when the bit rate is not greater than the bit rate limit.

Plain-language overview of each independent claim

(Claims 1, 10, 11, and 12 are independent; the rest depend from them.)

Claim 1 — Method (firewall-based inbound rate control).
At a firewall sitting between a sender and a receiver:

1. Sort the connection into one of several defined traffic classes.
2. Estimate the bit rate across a round-trip time between the two ends.
3. Receive the acknowledgment (ACK) coming back from the receiver.
4. If the measured bit rate exceeds a limit, hold up (delay) the ACK rather than passing it through.
5. If the bit rate is at or under the limit, release the ACK to the sender.

The practical effect: since TCP slows a sender when ACKs are slow to arrive, the firewall throttles inbound traffic without modifying the sender, receiver, or routers — this is the "ACK as a timing mechanism" idea described in the spec.

Claim 10 — Apparatus (the firewall server itself).
Same five-step function, but claimed as a machine using means-plus-function language: a computer memory plus classifying means, estimating means, receiving means, delay means, and transmitting means. Under § 112(f), the "means" terms are construed to cover the corresponding structures/interfaces described in the specification and their equivalents.

Claim 11 — Computer program product.
Same functionality claimed as code stored in a computer-readable memory that, when run by the firewall server's processor, causes the processor to classify the connection, estimate the RTT bit rate, receive the ACK, delay it when over limit, and forward it when under limit.

Claim 12 — Method (scheduling + TCP flow control, protocol-level).
Broader and differently focused than claim 1: in a TCP network,

1. Define multiple traffic classes, each with a priority;
2. Build a schedule for transmitting traffic according to those priorities; and
3. Use TCP flow control to enforce the schedule.

Notably, claim 12 does not recite a firewall or the ACK-delay mechanism; it recites priority-based scheduling enforced through native TCP flow control. Dependent claims 13–19 narrow it to outbound (13) or inbound (14) traffic, and to classes defined by traffic type/file type (15–16), source/business unit (17–18), and traffic requirement (19).

Supporting specification points worth noting

• The measurement approach is a sliding-window estimate of bit rate over a mean round-trip time for connections and aggregates, plus emulation of weighted fair queuing for inbound traffic to decide which class/connection to throttle.
• The window-size spoofing arithmetic is given in the spec, including the pseudocode using wmax, MSS, eprev, and an RTT-scaled timer for arbitrarily small bandwidth limits, with a ~25% over-limit allowance to compensate for TCP slow-start.
• Expressly stated extensions: applicability to Novell SPX, Xerox XNS, or any windowed, ACK-based flow-control protocol; and optional monitoring/billing/reporting features.
• The patent acknowledges that "guarantees" mean best efforts, not absolute guarantees.

If you want, I can next map each independent claim element-by-element against a specific prior-art reference (e.g., the cited US 6,038,216 to Packeteer or US 5,193,151 to Digital Equipment), or pull the full assignment/reassignment record from the USPTO Assignment database rather than relying on the Google Patents summary.

I'll research litigation involving US patent 6119235 across litigation databases and court records.

Let me search the specific litigation databases directly.

Let me search targeted litigation databases with the exact patent number and related parties.

Litigation Summary — U.S. Patent No. 6,119,235

Bottom line: I found no evidence of any litigation involving U.S. Patent No. 6,119,235. I was unable to identify any district court case, Federal Circuit appeal, or PTAB proceeding in which this patent was asserted or challenged. I must be explicit that my search was incomplete (see caveats below), so this should be read as "no known litigation identified," not as a certified negative.

What the patent is

• Number: US 6,119,235 B1 — "Method and apparatus for quality of service management"
• Inventors: Aseem Vaid and Sanjay Sawhney
• Original assignee: Ukiah Software, Inc.
• Priority: 1997-05-27 (provisional 60/047,752); filed: 1997-12-24; granted: 2000-09-12
• Chain of title (per the Google Patents record): Ukiah Software → Novell, Inc. (2001) → CPTN Holdings LLC (2011) → EMC Corporation (2011) → EMC IP Holding Company LLC (2016); subject to 2016 Dell/EMC security agreements later released.
• Status: Expired – Lifetime; anticipated expiration 2017-12-24. The patent has been expired for roughly eight years as of today.

Cases identified

None. No plaintiff, defendant, jurisdiction, case number, or filing date can be supplied for U.S. 6,119,235, because no case matching this patent appeared in the sources reachable to me.

Important: false positives I encountered (do NOT match this patent)

My searches repeatedly returned unrelated patents whose numbers merely end in "235." Flagging these so they are not mistakenly attributed to 6,119,235:

None of these relate to the Ukiah/Novell firewall QoS patent.

Related but distinct patent to be aware of

The '235 patent has a sibling from the same family/prosecution: US 6,341,309, "Firewall system for quality of service management" (Ukiah Software/Novell). Its existence is relevant because any litigation over the Ukiah QoS portfolio might name the '309 patent rather than—or in addition to—the '235 patent. I did not find litigation on the '309 patent either in my reachable sources, but I flag it as a place a portfolio assertion would likely have appeared.

Caveats on completeness

• I was able to reach general web results and some PTAB/PTAB-adjacent documents, but I was not able to complete a direct query of PACER, the Unified Patents litigation portal (https://portal.unifiedpatents.com/litigation/caselist), Docket Alarm, or CourtListener for this specific number before my search steps were exhausted.
• Several of my exact-number queries returned only the Google Patents page for US 6,119,235 itself, with no litigation links — consistent with, but not proof of, a clean litigation history.
• Given the patent's expiration in 2017 and its ownership by large operating companies (Novell → EMC/Dell) rather than a patent-assertion entity, a recent assertion campaign on this patent is unlikely. Any litigation would most plausibly have occurred in the early-to-mid 2000s during the Ukiah/Novell period, and would need to be confirmed via a PACER/docket-navigator search on the specific number.

Recommended verification steps

To close this out definitively, the following should be run directly (I could not complete them): a PACER "party/patent" search on 6119235; a Unified Patents litigation-portal lookup by patent number; a Docket Navigator / Lex Machina "patents asserted" report for 6,119,235 and 6,341,309; and a check of the Novell/CPTN/EMC assignment history for any recorded licenses or covenants not to sue that might explain a litigation-free history.

If you need a certifiable "no litigation" statement, I cannot give one based on the evidence gathered — I can state only that no litigation involving U.S. Patent No. 6,119,235 was identified in the sources I was able to reach.

I'll verify the canonical "no proceedings" record against live sources before writing.

Let me run a couple more targeted checks, including the sibling patent and reexamination history.

Proceedings overview

Zero (0) AIA trial proceedings have ever been filed against US 6,119,235 — no IPR, no PGR, no CBM — so the breakdown is 0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution denials, and the bottom-line defensive posture for a defendant is unusual: the patent is not "hardened" by surviving IPRs and it is not "softened" by losing any — it is simply untested at the Board and, critically, expired on 2017-12-24, which means there is no live patent term left to monetize and no § 315(e)(2) estoppel to navigate.

Confidence note: the canonical source (the structured USPTO Open Data Portal block in this prompt) affirmatively returns no AIA trial proceedings on file, and my independent web searches surfaced no IPR/PGR/CBM petition, institution decision, or FWD naming this patent. Absence-of-evidence caveats apply — I cannot prove a negative from web search alone — but the ODP-structured "none on file" record is the strongest available signal, and the 1998 priority date plus 2017 expiration put this patent well outside the typical NPE/IPR lifecycle.

No proceeding entries to report

I will not invent proceeding numbers to populate the per-proceeding template. There is nothing to put under a ### IPR20XX-XXXXX — {Petitioner} v. {Patent Owner} heading, and seeding one would be exactly the kind of fabrication this analysis is supposed to avoid. Instead, here is what the absence means and what adjacent records do exist.

What I checked and what came back:

Why the zero is structurally expected, not merely a search gap: the patent issued 2000-09-12, expired 2017-12-24, and its enforcement value window (roughly 2000–2010) largely predates the AIA trial regime — IPR under § 311 did not become available until 2012-09-16. A patent whose commercially interesting life was over before AIA trials existed would not naturally generate a docket. The related family member, US 6,341,309 B1 ("Firewall system for quality of service management," same 1997-05-27 priority, issued to Novell), is the more likely target if anyone ever challenged this family — and I found no PTAB activity on it either, though that is a separate patent and outside this mandate.

Strategic summary

Claim status: all 19 claims are UNTESTED at the Board — none canceled, none sustained. Claims 1–9 (the ACK-delay/firewall inbound rate-control method and its dependents), claims 10 and 11 (the means-plus-function firewall server and the computer program product), and claims 12–19 (priority scheduling enforced through TCP flow control) all stand exactly as issued, with no Certificate of Cancellation or reexamination certificate of record. The only narrowing of any kind is whatever happened during original prosecution and any inter partes reexam I could not confirm — do not assume any.

Estoppel landscape: there is none to speak of. Section 315(e)(2) estoppel runs only against a petitioner (and its privies/RPIs) that instituted an IPR and obtained an FWD. With no petition ever filed, no party is estopped from raising any § 102/§ 103 art — including art that was before the examiner and art that was cited by this patent in the intervening 25 years. That cuts both ways for a defendant: you have a clean slate on invalidity grounds, but you also get no free ride from a prior adjudication. There is also no § 325(d) "already considered by the Office" discretionary-denial risk from a prior Board proceeding, because there was none.

Pattern signals: none of the usual ones. No repeat petitioner, no serial IPRs, no Unified Patents or other defensive aggregator in the chain, and no patent-owner appellate aggression — logically, since there was nothing to appeal. The assignment trail is purely corporate: Ukiah Software → Novell (2001-06-20) → CPTN Holdings (2011-10-06) → EMC (2011-10-02 record) → EMC IP Holding LLC (2016-09-29), with Dell/EMC collateral-security records 2016–2022. This is a divested legacy portfolio asset, not a licensing program. One genuine signal in the record: this patent appears as a cited reference in a long list of later patents (the Google Patents "Cited By" table runs to ~140 entries, including Packeteer, Cisco, and Microsoft filings), which means its disclosure is at least a candidate prior-art anchor and a documented state of the art — useful if you are attempting to invalidate someone else's later QoS patent, and a hint that the art was well-known by the late 1990s.

Recommended next steps

If you are a defendant being asserted against: the first move is to check the date. For any conduct occurring on or after 2017-12-24, there is no infringement, because the term has run — damages are limited to pre-expiration acts, and 35 U.S.C. §§ 271/281 give no cause of action for post-expiration practice. Ask for the accused-acts date range in the demand letter; a demand citing claims 1, 10, 11, or 12 against current products is facially defective on term grounds alone. Six-year damages lookback under § 286 from a 2026 filing reaches back only to 2020, which is after expiration — meaning a suit filed today against current conduct likely recovers nothing.

If you nonetheless face a pre-2017 damages theory or an indemnity dispute: there is no FWD to link to and no claim has been canceled. Your invalidity case must be built from scratch, and the good news is that the ground floor is unpolluted. The most promising directions are the art the examiner relied on and the art cited in the "Citations (6)" table — US 5,103,384 (Tseung), US 5,193,151 (Digital Equipment, delay-based congestion avoidance — the closest conceptual cousin to ACK-delay rate control), US 5,560,851 (Arrowsmith), US 5,600,645 (France Telecom), US 5,815,667 (NCR, intelligent ACK-based flow control), and US 6,038,216 / US 6,298,041 to Packeteer ("Method for explicit data rate control in a packet communication environment without data rate supervision"), which is the family that most directly overlaps the ACK-spoofing concept and is itself the subject of a large IPR/citation cluster. Packeteer's teaching is worth careful comparison against claim 1's "delaying transmission of a receive acknowledgment signal when the bit rate is greater than a bit rate limit."

Practical framing: this is not a "patent hardened by surviving IPRs" and not a "claims 1–5 canceled" situation. It is a dead patent with a clean administrative history. The correct defensive posture is a term/expiration and damages-window attack first, with an invalidity posture held in reserve for any pre-2017-period theory.

Verification links (use these to confirm the negative before relying on it in a filing or an opinion letter, since my confirmation is search-based rather than an API pull):

• PTAB E2E / Patent Trial and Appeal Board proceeding search: https://ptacts.uspto.gov/ptabweb/
• PTAB decisions library (where an FWD would appear): https://www.uspto.gov/patents/ptab/trials/decisions
• CourtListener full-text search for citations and appeals: https://www.courtlistener.com/?q=%226%2C119%2C235%22
• USPTO Patent Center (reexam / prosecution history for 08/998,332): https://patentcenter.uspto.gov/

Flagged uncertainty (consistent with, not contradicting, the earlier summary): the earlier section correctly labelled the litigation finding "none located" rather than "none exists," and flagged the JP 6119235 number collision. I confirm both caveats extend to the PTAB record — a Japanese patent sharing the digits is easily mistaken for this one in search results, and one search hit I encountered even surfaced an unrelated inter partes reexamination of a different patent (the '660) whose claims happen to be numbered 1–6, 8, 10–14, 16–19, which is coincidentally close to this patent's claim set. Do not let that document migrate into a memo about 6,119,235.

I'll research the ownership chain specifics before reconstructing the record.

US 6,119,235 — Ownership Chain Reconstruction

Sourcing note up front (read this before relying on any reel/frame below): I was not able to query assignmentcenter.uspto.gov interactively — I have no direct API/UI access to that system in this session. Everything below is reconstructed from (a) the authoritative full text supplied in the prompt (Google Patents legal-events block, which mirrors USPTO assignment records), (b) SEC filings and DOJ/FCO records, and (c) legal-events blocks on sibling Novell/CPTN patents retrieved by search. Where a reel/frame is asserted, I say exactly which source it came from and at what confidence. Correspondent-of-record fields were not retrievable and I will not invent them.

Inventors

Addresses are confirmed from the front page of sibling patent US 6,341,309 B1 ("Aseem Vaid, San Jose, and Sanjay Sawhney, Santa Clara, both of Calif." — https://webapp1.dlib.indiana.edu/virtual_disk_library/index.cgi/[5628977](/patent/5628977)/FID2/og/html/1254-4/us06341309-20020122.html), which was filed the same day (App. No. 08/998,314) from the same provisional (60/047,752). Both are named assignors on the 1998-07-28 recorded assignment to Ukiah Software, Inc.

Unusual patterns: none observable in the record. I found no evidence that either inventor departed Ukiah within 12 months of filing, and I will not infer one. Worth noting structurally: the "inventors leave → portfolio fire-sale" pattern is subsumed here by a corporate event rather than an inventor event — Novell acquired Ukiah Software outright in June 1999, ~18 months after the December 1997 filing, so any inventor turnover is subsumed into the acquisition and is not separately visible in the assignment record.

Cross-check / minor correction to the prior section: the earlier summary listed the inventors without addresses. The '309 front page supplies the missing addresses and also confirms the two patents are siblings (same provisional, same filing date, different application numbers: 08/998,332 vs. 08/998,314).

Original assignee

Ukiah Software, Inc. — Campbell, California. Privately held.

• Product embodying the claims: Yes. Ukiah shipped the TrafficWare™ firewall/bandwidth-management server and the NetRoad FireWALL platform, both of which are named in the specification itself (col. describing "TrafficWare™ firewall server 110 from Ukiah Software, Inc."). Third-party documentation describes Ukiah's product as a policy-based bandwidth-management/firewall platform requiring NetWare 4.x/5.0 and at least two NICs — i.e., a real, shipped product, not a paper asset.
• Primary line of business: policy-based network management software — QoS/bandwidth management and network firewalls with directory-service integration (NDS).
• Current status: Acquired and dissolved as an independent entity. Novell, Inc. announced the acquisition in June 1999 (Tech Monitor: "last month it bought Ukiah Software, a privately held developer of policy-based network management software"; CNews reported the price at ~$50M while Novell publicly declined to disclose it). Ukiah's technology became Novell's ZENworks for Networks and the Novell "Firewall for NT" (Network World's retrospective confirms: "In 1999, Novell acquired Ukiah Software and incorporated Ukiah's policy-based management software into what would be called 'ZENworks for Networks'"). No bankruptcy, no fire-sale.

Assignment timeline

Reel/frame availability: the legal-events block for this patent, as supplied, lists conveyance text and dates but does not expose reel/frame numbers for the ownership assignments. Two reel/frames are recoverable from this patent's own release records (see entries 5–6 below, quoted verbatim from the "previously recorded at" text). Two more are inferred from sibling records and are marked medium confidence. I have not verified any of these against the Assignment Center UI.

1. 1998-07-28 (recorded) — Reel/frame not exposed

• Conveyance: Assignment of Assignors' Interest
• Assignors: Sanjay Sawhney; Aseem Vaid (both individually)
• Assignee: Ukiah Software, Inc.
• Correspondent: not retrievable — no correspondent field surfaced in any source I could reach.
• Context: initial inventor-to-company assignment, recorded ~7 months after the 1997-12-24 filing and before issue.

2. 2001-06-20 (recorded) — Reel/frame not exposed

• Conveyance: Assignment of Assignors' Interest
• Assignor: Ukiah Software, Inc.
• Assignee: Novell, Inc. (Provo, Utah)
• Correspondent: not retrievable.
• Context: acquisition. Timing discrepancy worth flagging: the Novell–Ukiah deal was announced and closed in June 1999, but this recordation is dated 2001-06-20 — roughly a two-year recordation lag (or a confirmatory/corrective assignment). This is not an inconsistency with the DOJ or press record, but it is the kind of gap that matters if you are dating a chain of title.

3. 2011-10-06 recorded / effective 2011-04-27 — Reel 027169/0200 (medium confidence)

• Conveyance: Assignment of Assignors' Interest
• Assignor: Novell, Inc.
• Assignee: CPTN Holdings, LLC, Washington
• Correspondent: not retrievable.
• Context: $450M asset sale via Patent Purchase Agreement dated 2010-11-21 (https://contracts.justia.com/companies/novell-inc-43423/contract/[699137](/patent/699137)/), consummated "immediately prior to" the Attachmate merger close on 2011-04-27. Novell's own 8-K of 2011-04-27 confirms completion of the sale of "certain identified issued patents and patent applications to CPTN Holdings LLC for $450 million in cash." Sibling Novell patents (e.g., US 6,502,131 B1, US 20080222425A1, US 20080313348A1) display the event ASSIGNMENT OF ASSIGNORS INTEREST ... NOVELL, INC.; REEL/FRAME:027169/0200, effective 2011-04-27 — hence the medium-confidence attribution of that reel/frame to this link.

4. 2011-10-02 recorded / effective 2011-09-09 — Reel 027016/0160 (medium confidence)

• Conveyance: Assignment of Assignors' Interest
• Assignor: CPTN Holdings LLC
• Assignee: EMC Corporation
• Correspondent: not retrievable.
• Context: phase-two distribution of the CPTN pool to its four owners (Microsoft / Oracle / Apple / EMC), exactly as described in the DOJ's 2011-04-20 press release (Release No. 11-491, https://www.justice.gov/archives/opa/pr/cptn-holdings-llc-and-novell-inc-change-deal-order-address-department-justices-open-source). Sibling Novell patent records display ASSIGNOR: CPTN HOLDINGS LLC; REEL/FRAME:027016/0160, effective 2011-09-09 — consistent with the 2011-09-09 effective date Google shows for this patent's EMC event.
• ⚠️ Ordering note (not a contradiction, but potentially confusing): the recordation date for the CPTN link (10-06) is four days after the recordation date for the EMC link (10-02), even though Novell→CPTN legally preceded CPTN→EMC by ~4.5 months in effective terms. Recordation order does not track effective order here.

5. 2016-09-21 (recorded) — Reel 040136/0001 (high confidence — quoted from this patent's own release text)

• Conveyance: Security Agreement
• Assignors (as recorded): approximately 17 Dell/EMC entities — ASAP Software Express, Inc.; Aventail LLC; Credant Technologies, Inc.; Dell International L.L.C.; Dell Marketing L.P.; Dell Products L.P.; Dell Software Inc.; Dell Systems Corporation; Dell USA L.P.; EMC Corporation; EMC IP Holding Company LLC; Force10 Networks, Inc.; Maginatics LLC; Mozy, Inc.; ScaleIO LLC; Spanning Cloud Apps LLC; Wyse Technology L.L.C.
• Assignee / secured party: The Bank of New York Mellon Trust Company, N.A., as Notes Collateral Agent
• Correspondent: not retrievable.
• Context: securitization — blanket IP lien recorded 14 days after Dell's acquisition of EMC closed (Dell Technologies formed 2016-09-07). The reel/frame is confirmed by this patent's own later release record: "RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL/FRAME (040136/0001)."

6. 2016-09-21 (recorded) — Reel 045455/0001 (high confidence — quoted from this patent's own release text)

• Conveyance: Security Agreement
• Assignors: same ~17-entity Dell/EMC list
• Assignee / secured party: Credit Suisse AG, Cayman Islands Branch, as Collateral Agent
• Correspondent: not retrievable.
• Context: securitization — parallel term-loan IP collateral package for the same financing. Confirmed by this patent's later release text: "(045455/0001)."

7. 2016-09-29 (recorded) — Reel/frame not exposed

• Conveyance: Assignment of Assignors' Interest
• Assignor: EMC Corporation
• Assignee: EMC IP Holding Company LLC
• Correspondent: not retrievable.
• Context: internal reorganization — Delaware holding-company restructuring of EMC's IP following the Dell acquisition. Not an arm's-length transfer to a licensing-only third party.

8. 2017-12-24 — not an assignment. Statutory/anticipatory expiration of the 20-year term (filing 1997-12-24). Redundant at this point but it is the terminal event for enforcement value.

9. 2021-11-03 (recorded) — Reel/frame not exposed

• Conveyance: Release by Secured Party
• Assignor / releasing party: Credit Suisse AG, Cayman Islands Branch
• Releasees: the Dell/EMC entity list
• Context: lien release / termination of security interest as the Dell LBO-era debt was refinanced or retired.

10. 2022-04-26 (recorded) — Reel/frame of the release not exposed (releases Reel 040136/0001)

• Conveyance: Release of Security Interest
• Assignor: The Bank of New York Mellon Trust Company, N.A., as Notes Collateral Agent
• Releasees: EMC Corporation (on behalf of itself and as successor-in-interest to Maginatics LLC), Dell Marketing L.P., EMC IP Holding Company LLC, Dell International L.L.C., ScaleIO LLC, Dell USA L.P., Dell Products L.P., and Dell Marketing Corporation in several successor capacities
• Context: lien release, housekeeping.

11. 2022-05-20 (recorded) — Reel/frame of the release not exposed (releases Reel 045455/0001)

• Conveyance: Release of Security Interest
• Assignor: The Bank of New York Mellon Trust Company, N.A., as Notes Collateral Agent
• Releasees: substantially the same Dell/EMC list
• Context: lien release, housekeeping.

Current holder (of record): EMC IP Holding Company LLC — i.e., a Dell Technologies subsidiary. Practically moot: the patent expired 2017-12-24.

Timeline diagram

timeline
    title Ownership of US 6119235
    1997 : Filed by Ukiah Software
    1998 : Inventors assign to Ukiah Software
    1999 : Novell buys Ukiah Software
    2000 : Patent issues
    2001 : Assignment recorded to Novell
    2011 : Novell sells portfolio to CPTN Holdings
         : CPTN distributes to EMC Corporation
    2016 : Security agreements recorded for Dell lenders
         : Transferred to EMC IP Holding
    2017 : Patent expires
    2021 : Credit Suisse releases security interest
    2022 : Two lender releases recorded

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT.
CPTN Holdings, LLC superficially matches the form: a single-purpose Delaware LLC with, per the DOJ's own description, "no sales or revenues" (Release 11-491), formed expressly to hold patents. But the substance is the opposite of an NPE shell: (a) its four owners are named operating companies — Microsoft, Oracle, Apple, EMC; (b) its ownership was fully disclosed and vetted by two competition authorities, not concealed behind a registered-agent address; (c) it dissolved its holdings within ~5 months, distributing the patents to its operating parents (recorded 2011-10-02 for the EMC leg) rather than retaining them for assertion. It is a consortium acquisition vehicle, not an assertion shell. The chain does not end at a licensing-only entity — it ends at EMC IP Holding Company LLC (2016-09-29), a subsidiary of an operating company.

2. Known asserter in the chain — NOT PRESENT.
No assignee in this chain appears on any of the listed NPE directories (Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, or Spangenberg entities). The assignees are: Ukiah Software → Novell → CPTN Holdings (MSFT/AAPL/ORCL/EMC) → EMC Corporation → EMC IP Holding Company LLC. My prior search on this patent number likewise surfaced no assertion, no IPR/PGR, and no district-court docket naming US 6,119,235. (Caveat repeated from the prior section: "none located," not "none exists" — the patent expired in 2017 and pre-2011 docket activity is thinly indexed online. Note in particular that recent hits on "the '235 patent" are US 10,715,235 in XR Communications v. AT&T and US 7,155,235 in IPR2024-00613 — different patents that merely share digits. Per the operating rules I do not auto-correct these; I flag them as non-relevant.)

3. Repeat correspondent across the chain — UNCLEAR / NO DATA.
I could not retrieve the correspondent-of-record field for any link in this chain from the sources available to me. I will not name a correspondent I did not see. This is the single largest evidentiary gap in this reconstruction; it is exactly the field that would let a follow-up analyst test for a recurring recording attorney across the Novell→CPTN→EMC→EMC IP Holding legs (all of which plausibly used the same outside counsel / in-house IP paralegal group).

4. Cascading transfers — PRESENT IN FORM, BENIGN ON THE FACTS.
Three recorded transfers inside ~5 months of effective time: Novell→CPTN (eff. 2011-04-27), CPTN→EMC (eff. 2011-09-09), with recordations bunched on 2011-10-02 and 2011-10-06. Under a strict reading this trips the "multiple consecutive assignments through chained LLCs in <24 months" box. But the cascade is documented, public, and court-supervised: it is the two-phase structure the DOJ described verbatim (phase one: CPTN acquires; phase two: "the patents would be allocated and distributed to each of the four owners"). No shared registered-agent address is needed to explain it, and no common principal is concealed. Treat as explained, not suspicious.

5. Pre-litigation transfer — NOT PRESENT.
No infringement suit naming this patent was located, so there is no transfer that can be dated within 6 months of a first suit. The nearest candidate, the 2016-09-29 transfer to EMC IP Holding, is an internal reorg three years after the Dell deal and ~15 months before expiration.

6. Bankruptcy fire-sale — NOT PRESENT.
Novell exited via a merger with Attachmate Corporation (completed 2011-04-27), not a Chapter 7/11. The patent sale to CPTN was a negotiated $450M asset sale, not a court-supervised 363 sale. No Kodak/Nortel/Polaroid pattern here.

7. Privateering — UNCLEAR, and on balance probably NOT PRESENT.
This is the closest call. The facts that point toward the pattern: Novell sold 861+ patents for $450M to a vehicle organized by Microsoft and co-owned by three of Novell's competitors (Apple, Oracle, EMC); the Open Source Initiative and FSF/FSFE jointly petitioned the DOJ and the German Bundeskartellamt arguing that "CPTN creates a cover to launch patent attacks against open source while creating for each principal a measure of plausible deniability" (https://opensource.org/blog/cptn). The facts that point away: the regulators imposed conditions that strip the vehicle's offensive utility — all acquired patents were taken "subject to the GNU General Public License, Version 2" and the OIN license, CPTN was barred from limiting which patents remain OIN-licensed, Microsoft had to sell its allocated share back to Attachmate (retaining only a license), and EMC was barred from acquiring 33 virtualization-related patents. And critically: no assertion against open source or anyone else ever materialized on this patent. On balance this is a documented competition-law event, not privateering. Mark unclear → leaning not present.

8. Defensive aggregator (anti-NPE) — PARTIALLY PRESENT, but the chain does not terminate at one.
The chain terminus is EMC IP Holding Company LLC (recorded 2016-09-29), a Dell Technologies operating subsidiary — not RPX, AST, LOT, Unified Patents, or OIN. So the literal criterion for this verdict bucket fails. However, a defensive-aggregator effect is documented for this specific portfolio: the DOJ/FCO consent conditions required every Novell patent sold to CPTN to be acquired subject to the Open Invention Network license (DOJ Release 11-491). Any follow-up analyst should treat this as "OIN-encumbered, not OIN-owned."

Verdict

Defensive / non-asserting — (closest fit; see the caveat, which is material)

Justification: the full ownership chain is Ukiah Software → Novell → CPTN Holdings → EMC Corporation → EMC IP Holding Company LLC (recordings dated 1998-07-28, 2001-06-20, 2011-10-02, 2011-10-06, 2016-09-29), terminating at an operating-company IP subsidiary with no intervening licensing-only NPE, and the Novell→CPTN leg (eff. 2011-04-27, ~$450M) was court-supervised and conditioned on OIN/GPLv2 encumbrances by the DOJ and German FCO, rather than being a free-and-clear transfer to an asserter. I located no assertion, no IPR/PGR, and no district-court docket on this patent, and it expired on 2017-12-24. Caveat: the taxonomy's literal definition of this verdict requires the chain to end at a defensive aggregator (RPX/AST/LOT/Unified/OIN); it ends at EMC IP Holding instead. If you require strict adherence to that definition, the correct verdict is Insufficient data, driven solely by the missing correspondent-of-record fields — but the substance is plainly non-NPE.

What would change this verdict: (a) recovery of the correspondent-of-record on reels 027016/0160, 027169/0200 and the 2016 EMC-IP-Holding record — if the same attorney/firm appears across the Novell→CPTN→EMC legs, signal 3 flips from "no data" to "present"; (b) any pre-2011 assertion of US 6,119,235 or its sibling US 6,341,309 against Novell-era competitors, which would flip the analysis toward operating-company assertion; (c) a 2016–2017 assertion by EMC/Dell against a competitor, which would flip it to operating-company assertion outright.

Verify at: https://assignmentcenter.uspto.gov/ (search by patent number 6119235; the alternative index https://assignment.uspto.gov/patent/index.html resolves to the same records). Ask specifically for the correspondent and execution date fields on each record — those are the two fields I could not obtain.

Cross-reference notes against the earlier sections

• No substantive contradiction with the prior summary's chain (Ukiah → Novell → CPTN → EMC → EMC IP Holding).
• Two clarifications: (1) the prior summary's ordering "EMC Corporation (2011-10-02 record) → CPTN Holdings (2011-10-06 record)" is correct as to recordation dates but inverts effective order — CPTN's acquisition was effective 2011-04-27 and the EMC distribution 2011-09-09; (2) the prior summary stated the litigation finding as "none located," which I confirm and extend: the apparent hits on "the '235 patent" in recent PTAB/EDTX materials are US 10,715,235 and US 7,155,235, not this patent.
• New material this section adds: confirmed inventor addresses (via US 6,341,309), the Novell–Ukiah acquisition date and price reporting, the Novell 8-K of 2011-04-27, the 2010-11-21 Patent Purchase Agreement, DOJ Release 11-491, and reel/frame 040136/0001 and 045455/0001 for the 2016 security agreements.

I'll verify the patent record at the USPTO and gather details on each cited reference.

Let me gather the remaining cited references and confirm the USPTO record.

Prior-Art Analysis — U.S. Patent No. 6,119,235

1. Record verified

The authoritative full text provided for US 6,119,235 A ("Method and apparatus for quality of service management," Vaid & Sawhney, Ukiah Software, app. 08/998,332, filed 1997-12-24, granted 2000-09-12, priority 1997-05-27 via provisional 60/047,752) lists exactly six examiner-cited U.S. patent references under "Patent Citations (6)." That is the set analyzed below. I did not auto-correct or substitute any number; the six are treated literally as they appear.

Governing law note: With a 1997-05-27 priority and 1997-12-24 filing, this patent is governed by pre-AIA 35 U.S.C. § 102. The relevant categories are § 102(a)/(b) (publication/patenting before the invention or more than one year before filing) and § 102(e) (a U.S. patent filed before the applicant's invention).

2. The six cited references at a glance

3. Reference-by-reference analysis

3.1 US 5,109,384 — Tseung, "Guaranteed reliable broadcast network"

• Citation: US 5,109,384 A; Appl. No. 486,082; filed 1990-02-27 (CIP of Ser. No. 07/266,473, filed 1988-11-02, which issued as US 5,036,518); Canadian priority 1989-10-31; inventor Lawrence C. N. Tseung; issued 1992-04-28. § 102(b) art (issued >1 year before the '235 filing).
• Description: A reliable one-to-many/many-to-many broadcast protocol using specialized stations (retransmission station, designated recorder station, playback recorder station). Its flow-control discussion is explicitly ACK-delay based: "In the one-to-one data communication environment, message acknowledgement provides an implicit flow control mechanism. If the receiving data processing station is slow or busy, it just delays the sending of message acknowledgement," and "the designated recorder station 28 slows down the message flow… by increasing the time interval between receiving the message… and sending the acknowledgement message." (https://patents.google.com/patent/US5109384A; full text via https://patentimages.storage.googleapis.com/0e/e6/e9/8060aa6b04fc04/US5109384.pdf).
• § 102 analysis: This reference does not anticipate any claim of the '235 patent. It does disclose the general concept of delaying an acknowledgment to regulate sender rate — an element of claim 1 — but it lacks (i) a firewall server coupling source to receiver, (ii) estimating a bit rate over a round-trip-time, (iii) comparison against a bit rate limit, (iv) classification of a connection into traffic classes, and (v) TCP. Its flow-control rationale is recovery-message-driven, not bit-rate-limit-driven. Relevance is as § 103 background showing ACK-delay flow control was known.

3.2 US 5,193,151 — Jain (DEC), "Delay-based congestion avoidance in computer networks"

• Citation: US 5,193,151 A; filed 1989-08-30; inventor Rajendra K. Jain; assignee Digital Equipment Corp.; issued 1993-03-09. § 102(b) art. (European counterpart EP 0 415 843.)
• Description: Each node measures round-trip delay on sending data and receiving an ACK, compares delays at different load levels, and increases/decreases load by adjusting window size or packet rate to operate at the "knee" of the throughput/delay curve. Claims 8–13 recite measuring delay between sending data and receiving the acknowledgement and changing the load in response (https://patents.google.com/patent/US5193151A; http://www.everypatent.com/comp/pat5193151.html).
• § 102 analysis: Does not anticipate the '235 claims. It is close on the "estimate over a round-trip … ACK timing" element but: (a) the decision variable is delay, not a bit rate compared to a bit-rate limit; (b) control is applied at the source node, not at an interposed firewall server; (c) it neither delays ACKs nor classifies connections into traffic classes. It is a legitimate § 103 reference for the RTT-measurement element of claim 1.

3.3 US 5,561,851 — Arrowsmith Technologies

• Citation: US 5,561,851 A; filed 1994-05-26; issued 1996-10-01; title "System and method for ensuring the availability of a radio data communications link." § 102(b) art.
• Description — verification limit: I was able to confirm the bibliographic record from the '235 front page but my tool budget was exhausted before I could retrieve this reference's full text/claims. Based on the title and its citation position in a QoS/flow-control art unit, it is directed to maintaining availability of a radio/serial data link (link-layer keep-alive/retransmission), not to gateway QoS.
• § 102 analysis: On the record available to me, it does not anticipate claims 1, 10, 11, or 12 — it discloses no firewall-based traffic classification, no bit-rate-over-RTT estimate, and no ACK-delay-to-limit mechanism. Flag: this conclusion is provisional pending retrieval of the reference's claim text. (See § 5.)

3.4 US 5,600,645 — France Telecom

• Citation: US 5,600,645 A; filed 1994-07-21; issued 1997-02-04; title "Bit rate reservation at switching nodes of an asynchronous network." § 102(e) art (U.S. patent filed 1994, before the '235 filing).
• Description — verification limit: Bibliographic record confirmed from the '235 front page; full text/claims not retrieved (tool budget). Title indicates ATM/asynchronous-network bit-rate reservation at switching nodes.
• § 102 analysis: Its subject matter (bit-rate reservation in connection-oriented switching nodes) is not the firewall/gateway ACK-delay mechanism of claims 1/10/11, nor the priority-scheduling-plus-TCP-flow-control of claim 12. It could only be relevant as § 103 art for the "bit rate limit" concept. Provisional conclusion — see § 5.

3.5 US 5,815,667 — Chien & Donnelly (NCR), "Circuits and methods for intelligent acknowledgement based flow control in a processing system network"

• Citation: US 5,815,667 A; Appl. No. filed 1995-11-28; issued 1998-09-29; assignee NCR Corporation. § 102(e) art (U.S. patent filed before the '235 invention/filing). European counterpart EP 0 777 363 A2/A3.
• Description: A management circuit that (a) monitors a first latency characteristic indicating network utilization and (b) monitors a second latency characteristic indicating efficiency of transmission of reception indicia (ACKs); control circuitry adjusts the transmission delay of reception indicia (ACKs) as a function of these latency characteristics, and separately adjusts retransmission delay. It also compares the transmission delay to a threshold. The patent states the ACK timer approach and ACK piggybacking are conventional (https://patents.google.com/patent/US5815667A; PDF: https://patentimages.storage.googleapis.com/aa/89/21/c24cf25b157170/US5815667.pdf).
• § 102 analysis: This is the second-most material reference and is arguably the closest prior art on the ACK-delay element of claim 1. However it does not anticipate:
  • Claim 1 / 10 / 11 — missing (i) interposition as a firewall server coupling a data source to a data receiver; (ii) classifying the connection into one of a plurality of traffic classes; and (iii) specifically estimating a bit rate over a round-trip time and delaying the ACK when that bit rate exceeds a bit rate limit (NCR keys the delay to a latency/efficiency characteristic, not to a bit-rate-limit comparison). Anticipation requires every element in a single reference; the classification and firewall limitations are absent.
  • Claim 12 — missing an explicit priority-based schedule enforced via TCP flow control (NCR is not TCP-specific; it addresses a generic processing-system network and also covers retransmission-delay control).
  • Role: Excellent § 103 reference when combined with a traffic-classification/scheduling reference (e.g., the '235's own FIG. 3–4 hierarchical model art) or with US 6,038,216.

3.6 US 6,038,216 — Packer (Packeteer), "Method for explicit data rate control in a packet communication environment without data rate supervision"

• Citation: US 6,038,216 A; Appl. No. 08/742,994; filed 1996-11-01 (CPA under 37 CFR 1.53(d)); issued 2000-03-14; inventor Robert L. Packer; assignee Packeteer, Inc. § 102(e) art (U.S. patent filed 1996-11-01, before the '235 priority/filing). Family: US 6,298,041, US 6,741,563, US 6,928,052; EP 1 031 163 B1 (https://patents.google.com/patent/US6038216A; PDF: https://www.docketalarm.com/cases/PTAB/IPR2020-00335/Inter_Partes_Review_of_U.S._Pat._6651099/docs/02-04-2020-Petitioner/Exhibit-1030-31-US_Patent_No_6,038,216_Packer.pdf).
• Description: "A method for explicit data rate control is introduced into a packet communication environment which does not have data rate supervision by adding latency to the acknowledgment (ACK) packet and by adjusting the size of the flow control window associated with the packet in order to directly control the data rate of the source data at the station originating the packet." Its claims recite "varying said data rate by sending said acknowledgment packet at a selected delay" (claim 1); rate control implementable at a third station in the data path between first and second stations (claim 3); and delay as a function of number of source packets received (claim 5). It expressly uses measured/smoothed RTT to weight the ACK delay. EP 1 031 163 B1 additionally cites US-A-5,042,029 (Hayakawa) as featuring "a system that delays acknowledgment packets during periods of congestion."
• § 102 analysis — the most material reference, but still not an anticipation of the issued independent claims:
  • Claim 1 / 10 / 11: Packeteer discloses the core "delay the ACK to throttle the source" mechanism and even measures RTT, but it does not disclose: (i) a firewall server that couples a data source to a data receiver (Packeteer's device is placed at/adjacent the server end system or at any point in the path, which is broader and differently claimed); (ii) classifying a connection into at least one traffic class from a plurality of traffic classes — the '235 claim 1 limitation added over the provisional disclosure; and (iii) the specific "bit rate … greater than a bit rate limit" comparison (Packeteer uses a target rate and window scaling). Because claim 1 requires all elements, Packeteer does not anticipate claim 1 as issued. It would anticipate a hypothetical claim omitting the classification/firewall limitations.
  • Claim 12: Packeteer does not recite priority-ordered scheduling of multiple traffic classes enforced through TCP flow control; it is a per-connection/circuit rate-control system. No anticipation.
  • Why the patent still issued over it: The most probable distinguishing limitations the examiner relied on are the firewall-server placement and, decisively, the traffic-class classification step (claim 1), which Packeteer's rate-control-device disclosure does not teach. This is a textbook "cited-and-overcome" reference.

4. Most relevant prior art — ranked

1. US 6,038,216 (Packeteer/Packer) — teaches the central inventive concept (ACK-delay + window adjustment to rate-control the source over a measured RTT). Primary § 103 reference, and the closest thing to § 102 art for the mechanism of claim 1; defeated only by the firewall-placement and traffic-classification limitations.
2. US 5,815,667 (NCR/Chien & Donnelly) — teaches adaptive ACK transmission-delay as a function of a monitored network characteristic; complements Packeteer for the ACK-delay element.
3. US 5,193,151 (DEC/Jain) — teaches RTT-delay measurement used to adjust source load (window/rate); supplies the "bit rate over a round-trip-time" measurement element.
4. US 5,109,384 (Tseung) — teaches ACK-delay as implicit flow control in a reliable-delivery protocol; older § 102(b) art showing the technique was known.
5. US 5,600,645 (France Telecom) — bit-rate reservation/limit concepts (§ 102(e)); peripheral.
6. US 5,561,851 (Arrowsmith) — link-availability art; least relevant on the face of the record.

No single one of the six anticipates any of claims 1, 10, 11, or 12. At least one limitation is missing from each — most commonly the firewall-server interposition, the connection classification into one of a plurality of traffic classes, or the specific bit-rate-relative-to-limit comparison trigger for ACK delay. The realistic attack is a § 103 combination (e.g., Packeteer '216 + Jain '151 + a traffic-classification/policy reference, or Packeteer '216 + NCR '567).

5. Verification limits and explicit caveats (do not over-read this analysis)

• Unretrieved full texts. My tool budget was exhausted before I could pull the full text/claims of US 5,561,851 and US 5,600,645. Their descriptions above rest on the '235 front-page citation data and titles, plus my general subject-matter knowledge. Their non-anticipation conclusions are provisional. A definitive analysis requires their claim sets and specifications.
• Anticipation vs. obviousness. Everything in § 3 is expressed as a § 102 element-by-element test; where I say a reference does not anticipate, I do not mean it is irrelevant — each of the four most relevant references is a viable § 103 building block.
• Additional, non-cited art that should be considered. The '235 specification itself concedes the prior art of TCP window flow control, slow-start, ICMP Source Quenching, and fair-queuing schedulers. The foundational non-patent references (RFC 793/1122; Jacobson slow-start; the citations appearing in the Packeteer front page such as RFC 793, RFC 1122, and TCP/IP Illustrated) are standard § 102(b)/§ 103 art and were not among the six examiner citations. Consider them in any full validity study.
• Citation-type caution. The Google Patents page has two lists: "Patent Citations (6)" (the examiner citations analyzed above) and "Cited By (74)" (third-party later citations). I analyzed only the six. Note that US 6,341,309 (Ukiah/Novell, "Firewall system for quality of service management," same 1997-05-27 priority) appears in "Cited By," confirming the sibling-family relationship noted in the earlier summary section; it is a related family member, not prior art to the '235 patent.
• Date and number integrity. I kept the "6119235" identifier literal. As flagged in the earlier sections, do not confuse this with JP 6119235 (Ricoh). Minor date inconsistency: the heading of this task states "Current Date: April 26, 2026," whereas the session date is 2026-09-28; neither affects the prior-art analysis, since all relevant dates predate 2000.

To make this certifiable, the next steps are: (1) retrieve the full claim text of US 5,561,851 and US 5,600,645; and (2) build a formal element-by-element § 103 chart for claim 1 against US 6,038,216 in view of US 5,193,151 and US 5,815,667, using the '235 prosecution history to confirm the exact limitations the examiner relied on for allowance.

I'll ground the prior-art references cited on this page before building the § 103 combinations.

Obviousness Analysis — U.S. Patent No. 6,119,235 under 35 U.S.C. § 103

0. Scope, source discipline, and contradictions flagged

This analysis builds on the two previously generated sections (bibliographic summary and litigation summary) and uses only the prior-art references listed on the page's "Citations (6)" section, plus the "Cited By" list where a reference is chronologically eligible as prior art. I do not re-summarize the abstract, claims, or assignment chain.

Contradictions / discrepancies to flag explicitly (per the strict no-auto-correction rule):

1. Priority date, one-day discrepancy. The authoritative page text says priority date 1997-05-27 (provisional 60/047,752). A Unified Patents record surfaced in my search shows US-6119235-A with "Priority Date: 1997-05-26." I treat 1997-05-27 as controlling (authoritative page text) and note that the discrepancy is immaterial — every reference used below predates even the earlier date.
2. Publication format. The earlier section rendered the number as "US 6,119,235 B1." The authoritative page shows US6119235A. Same document; label difference only.
3. Packeteer reference-date discrepancy. US 6,038,216's front page states Filed: Nov. 1, 1996 (Appl. No. 08/742,994). A third-party database (Unified Patents) lists 1996-10-31. Both precede 1997-05-27; I use the front-page date.
4. "Prior art" list size. The page presents two different lists: Citations (6) (references the examiner cited against '235) and Cited By (74/140) (references that cite '235). These are not the same thing. Almost all "Cited By" references post-date '235's priority and are therefore not prior art. I exclude them and say so where relevant.

Confidence caveat up front: I grounded the references on their abstracts, front matter (filing/priority dates, claims), and page excerpts retrieved via search — not by reading every column of every reference. Where an element mapping is inference rather than an express disclosure, I label it [inference] with a confidence rating. A full-text, line-by-line mapping should be done in a docket-quality validity opinion.

1. Governing legal framework

The application was filed 1997-12-24, so pre-AIA § 102/§ 103 applies (the AIA first-inventor-to-file provisions apply only to applications filed on or after 2013-03-16). Obviousness is assessed under Graham v. John Deere Co., 383 U.S. 1 (1966) — scope/content of the prior art, differences between the prior art and the claims, level of ordinary skill, and secondary considerations — as refined by KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007).

Key KSR-derived principles used here:

• A claim is obvious when it "combin[es] prior art elements according to known methods to yield predictable results," or when a "known technique [is used] to improve a similar device in the same way" (MPEP § 2143 rationales (A), (C), (D)).
• TSM is not the exclusive test. "[A]ny need or problem known in the field of endeavor at the time of invention and addressed by the patent can provide a reason for combining the elements." KSR, 550 U.S. at 420.
• Where there is "a design need or market pressure to solve a problem and there are a finite number of identified, predictable solutions, a person of ordinary skill has good reason to pursue the known options." Id. at 421.
• Predictable use of prior art for its established function in a new but similar field of use is obvious (In re O'Farrell; MPEP § 2144.04), as is an obvious design/placement choice where no new or unexpected result accompanies it (In re Kuhle; MPEP § 2144.06 rationales).

Level of ordinary skill (POSITA). A person with a B.S. in computer science or electrical engineering (or equivalent) plus roughly two to four years of experience in TCP/IP networking, including congestion/flow control and internetwork gateway or firewall design, and familiarity with RFC 793/1122, sliding-window flow control, RTT estimation, and the then-current literature on congestion avoidance and fair queuing. This is a relatively high-skill, well-populated art — a factor that cuts against non-obviousness, since the body of knowledge was dense and the design space well-mapped by 1997.

2. Prior-art inventory (page's Citations list only)

Excluded as post-dating the priority date (from "Cited By," not usable as § 102/§ 103 prior art against '235): US 6,625,118 (Nortel, priority 1998-05-08), US 6,560,243 (HP, 1999-04-30), US 6,789,203 (Sun, 2000-06-26), US 7,236,459 / US 7,720,085 (Packeteer, 2002-05-06), US 6,341,309 (the same-family sibling, same 1997-05-27 priority), and the Avaya/Alterwan/Valve families. Anyone building a § 103 case must not cite these.

Additional art I flagged but that is not on this page's list (verify before use): US 5,042,029 (Hayakawa, NEC) — described in the Packeteer/EP 1 031 163 B1 background as a system that "delays acknowledgment packets during periods of congestion," but "the period of delay is not determined relative to a target rate" — i.e., expressly not rendering Packeteer obvious; US 5,455,826 (Ozveren, rate-based flow control); US 5,426,635 (AT&T, adaptive control of windows and rates); US 5,359,593 (IBM, dynamic bandwidth estimation). These would strengthen a combination but are outside the instruction to use this page's prior art.

3. Claim 1 — element-by-element analysis

Claim 1 recites five elements: (a) firewall server coupling a data source to a data receiver; (b) classifying the connection into one of a plurality of traffic classes; (c) estimating a bit rate over a round-trip-time; (d) receiving a receive-ACK from the receiver; (e) delaying the ACK when bit rate > limit, transmitting it when bit rate ≤ limit.

Result: Every element of claim 1 is taught or suggested by the combination of US 6,038,216 + US 5,193,151, with US 5,815,667 as an alternative or reinforcing secondary reference for the "adjust ACK transmission delay at a gateway as a function of a measured latency/rate characteristic" element.

3.1 Combination A — '216 in view of '151

• '216 supplies the complete operative mechanism at an inline device: intercept the ACK, add latency, adjust the window, thereby forcing the sender to a target rate — without touching endpoints, which the '235 spec itself lists as a key benefit.
• '151 supplies the measurement limb the '235 claims: measuring the round-trip delay from data-sent to ACK-received, and using that measurement to modulate window size or packet rate.
• Motivation (KSR rationale (A) + (D)): Both references address the identical problem — TCP senders that ignore network conditions and congest a shared/slow link — using the same underlying signal (ACK timing). '216 expressly operates "without data rate supervision" in TCP/IP; '151 expressly operates in the same TCP/IP/ISO/OSI/SNA environment. A POSITA implementing an explicit rate controller would naturally need a rate estimate, and '151 teaches precisely how to derive one from RTT. There is no teaching away: '151's "without intervention by the router or server" preference concerns where the decision wholly resides in a pure congestion-avoidance scheme; it does not disparage measuring RTT at an intermediate node, and '216 already supplies the intermediary-based control architecture.

3.2 Combination B — '216 in view of '667

• '667 makes the ACK-delay limb explicit as a claim element rather than an implementation detail: a management circuit "operative to adjust a transmission delay associated with the transmission of the reception indicia... as a function of the latency characteristic," where the latency characteristic is "indicative... of a utilization level of the network," and the circuit may sit at a gateway (cl. 10).
• Motivation: Same field (packet-network ACK-based flow control), same problem (overload/utilization control), overlapping disclosure ('667's background discusses the same ACK-timer problems '216 addresses). Combining them yields nothing more than the predictable aggregation of '216's target-rate-driven ACK delay with '667's latency-threshold-driven ACK delay. Obvious as a simple substitution/duplication of known techniques (MPEP § 2143 (B)).

3.3 Combination C — '216 + '151 + '600,645 (adds class granularity)

• '600,645 teaches storing a per-channel current bit rate at each node, accepting a requested bit rate in a reservation cell, and confirming an adopted bit rate via an ACK cell, with partial satisfaction proportional to available bit rate across multiple channels sharing an outgoing multiplex channel.
• Motivation: This is the per-class/per-flow rate-limit bookkeeping layer that claim 1's "bit rate limit" and the dependent claim 3 ("determining the bit rate limit") require. A POSITA managing several simultaneous flows over one access link in 1997 had a finite number of identified solutions — per-class/per-flow rate reservation and accounting, of which '600,645 is a concrete, analogous teaching — and would apply it to a TCP gateway. KSR, 550 U.S. at 421.
• Cross-domain note: '600,645 is ATM, not TCP/IP. That is an analogous art question, but the field of endeavor is the same (data-network bandwidth allocation and rate reservation), and the problem addressed (allocating a shared outgoing link among channels requesting bit rates) is the same. Under MPEP § 2144.04, using the ATM rate-reservation technique to organize per-class limits in a TCP gateway is a predictable use for an established function. Confidence: moderate-high.

4. Claims 2–9 (dependents of claim 1)

5. Claim 12 — the broadest independent claim (and the most exposed)

Claim 12 requires only: (i) a TCP network; (ii) multiple traffic classes each with a priority; (iii) a schedule built according to those priorities; and (iv) using TCP flow control to limit the flow according to the schedule. It does not require a firewall, an ACK delay, or an RTT estimate.

Primary attack — § 103 over US 6,038,216 in view of US 5,600,645, and in further view of the applicant's own admitted prior art.

• (i) TCP: '216.
• (ii)–(iii) Per-class priorities and scheduling: '600,645 teaches per-channel bit-rate reservation with proportional allocation among contending channels. Separately, the '235 specification itself admits that "allocat[ing] output bandwidth per traffic class... by using a class of scheduling methods referred to as fair queuing algorithms" and "combin[ing] such methods with priority based schedulers in order to provide latency guarantees" were known techniques (see the spec's Outbound Control / Packet Scheduling section). Statements in the specification describing the problem and known approaches are admissions of prior art usable against the applicant (MPEP § 2129, In re Nomiya / In re Font line of reasoning).
• (iv) Using TCP flow control to enforce the schedule: this is the entire thesis of '216 — controlling TCP source rate via ACK latency and advertised window, without modifying endpoints.

Motivation: '216's stated purpose is network-level bandwidth management, "i.e. policies to assign available bandwidth from a single logical link to network flows." A policy that assigns bandwidth across classes is the same problem with coarser granularity. '600,645 supplies a concrete, analogous mechanism for class-level rate books. Combining a known fair-queuing/priority scheduler (admitted) with a known TCP-flow-control enforcement mechanism ('216) yields only the predictable result of the two known functions operating together — the essence of KSR rationale (A).

Assessment: Claim 12 is the weakest claim in the patent. Even standing alone, its elements are a near-verbatim recitation of what the specification concedes the art already did (fair queuing + priority scheduling + TCP window control), with no recitation of the novel ACK-delay mechanism that gives claims 1/10/11 their apparent novelty.

Claims 13–19 (outbound; inbound; classes by traffic type; classes by file type; classes by source; business units; traffic requirement) are all narrowing field-of-use enumerations of claim 12's "traffic classes" element. They add no structural element and would fall with claim 12 under KSR's design-choice/obvious-variation rationales (MPEP § 2144.06). Claim 16 ("traffic types includes file types") and claim 18 ("sources includes business units") are essentially restatements of the very classification taxonomy the '235 specification lists as conventional.

6. Claims 10 and 11

Claim 10 (apparatus, means-plus-function). Post-Williamson v. Citrix Online, LLC, 792 F.3d 1339 (Fed. Cir. 2015) (en banc), the "classifying means," "estimating means," "receiving means," "delay means," and "transmitting means" terms are construed as § 112(f) means-plus-function limitations, limited to the structures disclosed in the '235 specification and their equivalents. This has two opposite effects worth noting:

• It narrows the literal scope of claim 10 to the disclosed firewall-server structures (processor 360, memory 370/380, network interface 350).
• It does not rescue patentability: the disclosure of structure is generic (a PC-class server running TrafficWare™ software). On the § 103 side, the same combinations in § 3 render the claimed function obvious — the question is whether the disclosed corresponding structure (a general-purpose networked server executing rate-control software) is anything more than the predictable hardware for the claimed function. It is not, in my assessment. Confidence: high.

Claim 11 (computer program product). Same functional elements as claim 1, claimed as code in a computer-readable memory. This is the classic functional-claiming-of-software approach that adds no patentable weight over claim 1 where the specification discloses only generic hardware/software (cf. the treatment of Beauregard-style claims in In re Beauregard, 53 F.3d 1583 (Fed. Cir. 1995) — enablement, but no heightened non-obviousness). Anticipated/obvious to the same degree as claim 1. Confidence: high.

7. Motivation to combine — consolidated (and where the motivation is weakest)

Strong, cross-cutting motivations:

1. Same field, same problem, same signal. All primary and secondary references deal with packet-network rate/congestion control. '216 and '235 both control TCP source rate via ACK/window manipulation; '151 estimates the network's operating point from RTT; '667 adjusts ACK emission delay from a latency characteristic; '600,645 reserves per-channel bit rates confirmed by ACK cells. The references converge on the same technical lever — the acknowledgment path — which is precisely what makes combination predictable. KSR, 550 U.S. at 417 ("if a technique has been used to improve one device, and a person of ordinary skill in the art would recognize that it would improve similar devices in the same way, using the technique is obvious").
2. Market/design pressure. The '235 specification's own background documents the 1990s Internet congestion problem, the escalating demand for bandwidth management, and the inadequacy of link upgrades and of endpoint-only TCP congestion control. '216's background makes the identical complaint and proposes the identical class of solution.
3. Finite, identified, predictable solutions. Controlling inbound traffic at a chokepoint by manipulating ACK timing was one of a small, enumerated set of then-available options (ACK pacing, window clamping, ICMP source quench, queue management). Choice among them with a reasonable expectation of success is "obvious to try." KSR at 421.
4. Placement in a firewall is a design choice with no new result. The '235 claims place the mechanism in a "firewall server." A firewall is, functionally, an inline gateway in the data path — exactly where '216 places its rate control device ("a separate dedicated machine in the communication path") and where '667 places its management circuit (node or gateway). No new or unexpected result is attributed to the firewall location beyond administrative convenience, which the '235 specification itself touts ("a single point... to manage telecommunication traffic"). MPEP § 2144.06 (obvious design choice); § 2144.04 (similar field of use).
5. Interchangeability / substitution. '216's use of computed ACK delay and '667's use of threshold-based ACK delay are interchangeable ways of implementing the same scheme; substituting one for the other to obtain the claimed binary comparison is a simple substitution of known elements (MPEP § 2143 (B)).

Where the motivation is weakest (candidate patentee arguments):

• '151's "without intervention by the router or server" language. '151 expressly seeks a scheme that operates "at each node individually, without intervention by the router or server." A patentee could argue this teaches away from a gateway-implemented controller. Rebuttal: (a) '151's statement is about avoiding network-generated feedback bits and router overhead in a congestion-avoidance scheme; it is not a disparagement of intermediate-node measurement; (b) '216 — not '151 — is the primary reference supplying the gateway architecture, so no combination of '151's teaching with '216's architecture is needed; '151 contributes only the RTT measurement element, which '151's own disclosure supports at any node including the source; and (c) a teaching-away must be such that a POSITA would be dissuaded from the claimed invention, not merely from a preference (In re Fulton; MPEP § 2145). Assessment: weak-to-moderate argument, unlikely to defeat claim 1 on its own.
• Cross-domain art ('600,645 is ATM). The ATM/FRP art is a different transport paradigm (cells, cells-per-second reservations, no TCP windows). Patentee can argue non-analogous art or lack of reasonable expectation that ATM reservation semantics transfer to TCP ACK manipulation. Rebuttal: the field of endeavor (packet-network bandwidth allocation on a shared outgoing link) is the same, and '600,645's bit-rate-per-channel bookkeeping with ACK confirmation is structurally the same control loop. Class-level limits can equally be supported by the Packeteer classification family or by the '235's own admitted fair-queuing art, so '600,645 is not load-bearing for the claim-12 attack. Assessment: moderate argument as to '600,645 specifically; does not rescue claim 12.
• "Classifying into traffic classes" placement in independent claim 1. This is the element for which the page's six references give the weakest express support ('216 speaks in terms of flows and target rates; the class-schema language is more prominent in Packeteer's sibling classification patents and in the '235's own admissions). Assessment: this is the most plausible single point of attachment for a validity defense of claim 1. It should be probed with full texts.

8. Secondary considerations

• No adjudicated validity. The previously generated litigation section found no litigation, PTAB proceeding, or CAFC appeal involving U.S. 6,119,235 in the reachable sources. There is accordingly no judicial or PTAB holding of non-obviousness, no competitor copying finding, and no nexus-creating commercial-success record to weigh. In the Graham framework, this factor is neutral — the absence of secondary-consideration evidence removes the strongest potential rebuttal to the prima facie case.
• Licensing / acquisition value is weak evidence. The Ukiah → Novell → CPTN → EMC chain reflects portfolio acquisition, not product-level commercial success attributable to the claimed ACK-delay feature. Under In re GPAC / Wm. Wrigley Jr. Co. v. Cadbury Adams, portfolio or block-licensing value generally lacks the required nexus to the claimed invention.
• Industry praise / long-felt need. The 1997 bandwidth-management market (Packeteer PacketShaper, Ukiah TrafficWare, and others shipping concurrently) suggests the need was already recognized and being solved by multiple actors in the same timeframe — a negative secondary consideration (simultaneous independent invention), not a positive one. Both '216 (filed 1996-11-01) and '667 (filed 1995-11-28) predate '235's 1997 priority and address the same problem.
• Expiration. The patent expired 2017-12-24. Practically, § 103 analysis of '235 today is relevant only to retrospective matters (e.g., past damages, licensing audits, or estoppel/validity representations), not prospective exclusion.

9. Bottom-line conclusions

Overall assessment: On the record available, claims 12–19 look the most vulnerable to a § 103 challenge and, indeed, come close to the admitted prior art of the '235 specification itself. Claims 1–6 and 10–11 are likely obvious over US 6,038,216 in view of US 5,193,151 (and/or US 5,815,667), with the "classifying into traffic classes" element of claim 1 being the one limitation that most needs a dedicated, full-text secondary reference to make an airtight case. Claims 7–9 are moderately vulnerable and depend substantially on which classification reference is used.

10. Verification steps outstanding (do not treat § 9 as a certified opinion without these)

1. Full-text read of US 6,038,216 and US 6,298,041 to confirm the classification and per-class rate-limit disclosure, rather than inferring it from the flow of the '216 abstract and the family's later patents. The exact specification pages to target are the rate-control device placement discussion and the delay-scheduling flowchart.
2. Retrieve the actual claims of US 5,193,151 (I obtained claim language via EveryPatent and the DVL/EU counterparts; confirm against the printed patent columns 12+).
3. Determine whether the examiner's citation of US 6,038,216 in '235's "References Cited" was as an applied reference or merely listed. If it was applied and overcome with argument, that argument (and any resulting estoppel/inference) is material to a § 103 challenge.
4. Confirm US 5,600,645's provisioning interface for the "user-definable" limitation of claim 7.
5. Confirm the one-day priority discrepancy (1997-05-26 vs. 1997-05-27) against the USPTO PatentCenter record for 08/998,332, in case any of these references sits within a one-day margin (none currently does).
6. Sourcing note on the '216 docket exhibit I retrieved: the US 6,038,216 PDF appears as an exhibit in IPR2020-00335 (concerning U.S. Pat. No. 6,651,099) at docketalarm.com — a useful authenticated copy for an opinion appendix, and evidence that '216 is widely treated as the seminal explicit-rate-control reference.