Invalidity dossier

US 6798746

Method and apparatus for implementing a quality of service policy in a data communications network

Current assignee: Cisco Technology Inc

Added 9/24/2026, 3:40:04 AM

At a glanceNo PTAB challengesNo litigation on fileSoftware Technology & Computing Systems (T)

Active provider: DeepSeek · deepseek-flash

Patent summary

Title, assignee, inventors, filing/issue dates, abstract, and a plain-language overview of the claims.

✓ Generated

Patent Overview — US6798746B1

Title: Method and apparatus for implementing a quality of service policy in a data communications network

Assignee: Cisco Technology, Inc. (current and original assignee listed).

Key dates: Prior art date 1999-12-18; application US10/156,971 filed 2002-05-28; granted/publication date 2004-09-28; adjusted expiration 2020-06-19; legal status listed as expired – lifetime.

Inventors: Raymond J. Kloth, Thomas J. Edsall, Michael Fine, Dinesh G. Dutt.

Purpose: The invention relates to data communications networks and, more particularly, to implementing a QoS policy so as to prioritize network traffic into multiple service levels and give preferential treatment to different classes of data traffic. It addresses the problem of identifying and grouping transmissions for preferential or restricted treatment at the full data rate, without introducing delays or bottlenecks, and without depending on end hosts to categorize packets via the Layer 2 CoS or Layer 3 ToS fields.

Plain-language scope: Per the supplied text, a content addressable memory (CAM) holds flow information for each active flow passing through a node. Each CAM entry (corresponding to an active flow) has an associated packet counter, a bytes-seen counter, a token bucket, and a contract value or committed access rate. Each flow is assigned one of multiple output queues and optionally at least one output queue threshold value. A token bucket algorithm per flow determines whether packets exceed a committed access rate; such packets may be dropped, or modified to reflect an alternate output queue and/or threshold before being sent to the selected queue for transmission. An access control list CAM (ACLCAM) holds masked flow information (e.g., IP source/destination addresses, protocol types) and returns an N-bit index in response to QoS lookups based on best match, providing single clock-cycle lookups.

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

What the excerpt does not establish: It does not supply the full claim set, the detailed description, drawings, or dependent-claim limitations. It does not establish prosecution history, claim construction, validity, or the accuracy of the listed assignee or legal status. No litigation or ownership-transfer information is included.

Generated 10/15/2026, 11:22:57 PM

Cases on file (0)

Specific litigation cases in our database that name US patent 6798746. The free-form analysis below may also discuss cases beyond this list.

No cases on file mention this patent. Upload a CSV or add a case manually in Admin → Manage litigation cases.

Litigation summary

Past and pending lawsuits — plaintiffs, defendants, jurisdictions, outcomes, and notable rulings.

✓ Generated

I'll research litigation involving US patent 6798746 across patent litigation databases.

Those results reference unrelated patents (Ethicon's '874, Weber's grill '874). Let me search litigation-specific databases.

Let me dig into litigation-specific sources and check whether this patent was ever asserted.

Litigation Search Results — U.S. Patent No. 6,798,746

Bottom line: I found no evidence of any litigation involving U.S. Patent No. 6,798,746. No district court actions, ITC investigations, PTAB proceedings, or CAFC appeals asserting or challenging this specific patent surfaced in my searches. Below is what I checked and the reasoning, so you can assess reliability.

Patent identity (verified, so as not to conflate with similarly numbered patents)

  • Patent No.: US 6,798,746 B1
  • Title: "Method and apparatus for implementing a quality of service policy in a data communications network"
  • Assignee: Cisco Technology, Inc. (original assignee)
  • Inventors: Raymond J. Kloth, Thomas J. Edsall, Michael Fine, Dinesh G. Dutt
  • Priority date: 1999-12-18; Continuation filed: 2002-05-28; Granted: 2004-09-28
  • Status: Expired – Lifetime; adjusted expiration 2020-06-19
  • Source: https://patents.google.com/patent/US6798746/en

The short remaining term (expired June 2020) is itself a practical reason the patent would be an unlikely candidate for assertion litigation.

What I searched and what I found

  1. Google Patents page for US6798746B1 — The page shows a "Cited By (49)" list (forward citations) and a "Cited By" table of later patents/publications. Critically, it contains no "Litigation" / "Lawsuits" section, which Google Patents typically populates when litigation is registered. Forward citations are not litigation.

  2. General and litigation-oriented searches ("US patent 6798746 litigation," "6798746 patent lawsuit defendant," "Cisco 6,798,746 patent litigation," "6798746 IPR PTAB Cisco," and a search targeting the Unified Patents litigation portal). These returned:

    • Unrelated patents that merely share the trailing digits "874" — e.g., Ethicon's surgical-stapler '874 patent (ITC/§112 dispute) and Weber's grill '874 patent (N.D. Ill. case 1:13-cv-01686). These are different patents and I flag them only to explain why raw "874" hits are false positives.
    • Other Cisco litigation (e.g., Centripetal v. Cisco, Packet Intelligence v. Cisco, Spherix v. Cisco, Cisco v. Arista, Quicker Connections v. Cisco) — none of these involves 6,798,746.
    • Academic/citation uses of 6,798,746 (e.g., a Chinese patent CN1767496B citing it as prior art) — citations, not litigation.
  3. The Unified Patents portal (https://portal.unifiedpatents.com/litigation/caselist) did not surface any case tied to this patent number in the returned results.

Important limitations and caveats

  • My searches were constrained and did not include a direct, complete query of PACER's full docket database or a dedicated Docket Navigator / Lex Machina lookup keyed precisely to this patent. Those databases are the authoritative sources; a subscription-based, patent-number-specific query there would confirm the negative.
  • It is entirely possible that a short-lived or settled suit exists that did not surface in web-indexed results. I cannot rule that out with certainty, but I found zero affirmative indications of any such case.

Conclusion

Based on the sources I could reach, no litigation (district court, ITC, PTAB, or CAFC) involving U.S. Patent No. 6,798,746 is known. I am not fabricating any case details, because none were found. To make this a definitive negative, the next step would be a patent-number-exact query on Docket Navigator and PACER/Justia (both allow 6,798,746 as a search key), plus a check of the USPTO PTAB case search and the ITC EDIS system for Section 337 complaints naming the patent.

If you'd like, I can attempt more targeted queries (e.g., a specific NPE that might have acquired Cisco networking patents, or a specific Cisco product/QoS technology line) to try to close the gap.

Generated 10/1/2026, 3:00:56 PM

Proceedings on file (0)

All PTAB activity →

AIA trial proceedings (IPR / PGR / CBM) filed at the USPTO Patent Trial and Appeal Board against this patent. Sourced from the USPTO Open Data Portal and refreshed every six hours; each proceeding number deep-links to the PTAB E2E docket.

No PTAB proceedings on file. This patent has not been challenged via IPR, PGR, or CBM. The absence is itself a signal — well-asserted patents eventually attract IPRs. The LLM analysis below may surface filings the ODP feed hasn’t indexed yet.

PTAB challenges

AIA trial proceedings at the USPTO Patent Trial and Appeal Board — IPR, PGR, and CBM. Petitioners, judge panels, claim-level invalidation outcomes from Final Written Decisions, and Federal Circuit appeals. The single most important defensive datapoint after litigation history.

✓ Generated

I'll research PTAB activity on US 6798746. Let me start with targeted searches.

Let me dig deeper with more specific queries.

Let me run a few final targeted checks to confirm the absence.

PTAB proceedings overview

Total AIA trial proceedings on US 6798746: 0. The USPTO Open Data Portal returns no IPR, PGR, or CBM proceedings for this patent, and independent web searches for the patent number against PTAB dockets (Docket Alarm, PTAB E2E, CourtListener) surfaced none. The breakdown is therefore 0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution denied — there is nothing to list, and the bottom-line defensive posture is that the patent has never been tested at the PTAB, so all 57 claims remain statutorily intact and untested. I could not verify any proceeding, so I will not manufacture one.

I want to be explicit about what I checked and what the negative result means, because "no PTAB activity" is itself the substantive finding here.

No proceeding to report

There is no {PROCEEDING_NUMBER} entry to format. My searches covered:

  • The patent/assignee combination ("US6798746" + Cisco + IPR/PTAB) — returned only the Google Patents bibliographic page and third-party documents that merely cite 6798746 as prior art (e.g., a CN1767496B IDS listing, a Cisco/Puerto Rico-type IPR exhibit list where the number appears in an information-disclosure statement, and unrelated PTAB filings such as the Cisco v. Portsmouth IPR2024-00505/00506/01450 family concerning entirely different patents).
  • The inventors (Kloth, Edsall, Fine, Dutt) — surfaced other Cisco patents (e.g., 6,735,201; 6,785,274) but no challenge to 6798746.
  • General litigation sweeps tying Cisco to 6798746 — turned up Cisco as a defendant in unrelated matters (Paltalk, Sable, Uniloc, Centripetal, Packet Intelligence) but no case in which 6798746 was asserted, and no resulting IPR.

Caveat on confidence: The absence of PTAB activity is well-supported for the IPR/PGR/CBM dockets that are publicly indexed, but I cannot rule out a very recent or poorly-indexed filing, and I did not have working access to a live PTAB E2E party-name search within this session's step budget. Treat "zero proceedings" as the strong default, not a certified null.


Strategic summary

Claim status — everything is untested. None of claims 1–57 of US 6798746 has been canceled, narrowed, or even construed in an AIA trial. Claims 1 and 20 (the two independent method claims), claims 35, 43, and 46 (the independent apparatus claims), and every dependent claim remain fully in force. There is no reissue, no reexamination certificate, and no certificate of cancellation in the record I could find. Contrast this with heavily-litigated Cisco patents where the PTAB has wiped out whole claim families — nothing analogous exists here.

Estoppel landscape — § 315(e)(2) estoppel has not attached to anyone. Because no IPR/PGR was ever instituted, no petitioner is barred, and no privy of any petitioner is barred. A defendant facing assertion today can file a fresh IPR/PGR on any § 102/§ 103 ground without worrying that a predecessor challenger already spent the ground. Two structural notes for planning: (1) the patent's priority date is 1999-12-18 (parent application 09/213,105, a continuation), so the AIA first-inventor-to-file provisions do not apply — this is a pre-AIA patent, and § 102(a)/(b)/(e) art of the pre-AIA regime governs; and (2) 6798746 is a claimed continuation, so any challenge must account for the parent's prosecution history and the possibility of the patent owner relying on the earlier effective filing date for prior-art purposes. The strongest realistic attack vectors are § 103 obviousness over 1990s QoS/flow-classification art (token bucket, WRED, TCAM/ACL-based classification, per-flow queue selection) and § 112 written-description/indefiniteness on the "codepoint" and "aggregate flow table" constructs — none of which has been tested.

Pattern signals. There is no petitioner to identify, no repeat-filer pattern, no defensive aggregator (Unified Patents or similar) in the chain, and no Federal Circuit appeal because there is no underlying FWD. The salient signal is the absence: 6798746 is owned by Cisco Technology, Inc. — the original assignee and an operating company — rather than by a monetization vehicle. Well-asserted patents attract IPRs; a patent that has never drawn a single PTAB petition is consistent with a patent that has not been aggressively asserted against third parties, and/or one that defendants have chosen to design around rather than fight. I found no litigation asserting 6798746 in the sources searched. That cuts both ways for you: the patent is unhardened, but it is also unproven — a troll-style "this patent has been invalidated" demand letter would be false, while a defense-side "we'll just IPR it" assumption has no track record to lean on either.


Recommended next steps

  1. If you are a defendant: there is no FWD to link to and no claims are canceled. Do not rely on any claim-invalidation narrative — none exists. Pull the prosecution history of application 09/213,105 and the 10/156,971 continuation directly from USPTO PatentCenter to build a § 112 and § 103 record, since nothing has been litigated at the PTAB.

  2. If you are evaluating a demand: check the asserted claim numbers against the live claims (all of 1–57 issue on the 2004-09-28 grant; no certificates of cancellation on record). Any representation that claims have been invalidated in an IPR is inaccurate as of 2026-10-01.

  3. Filing posture: because no estoppel applies and the patent is pre-AIA with a 1999 priority date, an IPR petitioner can reach a broad field of pre-1999 printed-publication and patent art under §§ 102(a)/(b)/(e), and may also consider PGR-style § 112 grounds if any claim has a post-AIA-effective priority claim (there is none apparent — confirm via the file history). Note the § 315(b) one-year bar runs from service of a complaint alleging infringement of 6798746; since I found no such complaint, verify service dates before assuming a bar exists.

  4. Verify before you file. Confirm the null result on PTAB E2E by party name ("Cisco Technology") and on the patent-number field one final time; a proceeding filed within the last few weeks may not yet be in the ODP ingest or the search index. If a proceeding does exist, request the institution decision and FWD papers by proceeding number from the PTAB Decision database and re-run this analysis.

No PTAB activity is on file for US 6798746. The absence is the finding: the patent is untested, un-estopped, and fully enforceable unless and until someone files — and no one has.

Generated 10/1/2026, 3:01:03 PM

Ownership chain (1)

Asserters network →

Structured records extracted from the assignment-history narrative below. Each entity links to its full ownership-network profile.

  1. 2002 · Assignment

    Raymond J. Kloth; Thomas J. Edsall; Michael Fine; Dinesh G. DuttCisco Technology, Inc.

    routine employee invention assignment

Assignment history

Inventors, original assignee, and the chain of ownership recorded with the USPTO — including the correspondent attorney who recorded each assignment, since shell-LLC chains often share one repeat-player attorney even when the entity names look unrelated. Surfaces NPE / patent-troll patterns: shell-entity transfers, known asserters in the chain, repeat correspondent fingerprints, pre-litigation assignments, and bankruptcy fire-sales.

✓ Generated

I'll research the assignment record for US patent 6798746, starting with the USPTO Assignment Center and cross-referencing other sources.

Assignment Record Reconstruction — US Patent No. 6,798,746 B1

Data-access caveat (stated up front): My tool budget for this session was exhausted before I could load the USPTO Patent Assignment Center result page for this patent directly. The findings below are built from Google Patents legal events, the issued patent front page, FreePatentsOnline's bibliographic record, and targeted searches of USPTO legacy-assignment PDFs. Where a reel/frame could not be verified, I say so rather than inventing one. The definitive confirmation step (an exact patent-number query at the Assignment Center, linked at the end) remains open.


Inventors

Inventor Residence of record Employer at time of filing
Raymond J. Kloth Mountain View, CA Cisco (Systems/Technology)
Thomas J. Edsall Cupertino, CA Cisco (Systems/Technology)
Michael Fine San Francisco, CA Cisco (Systems/Technology)
Dinesh G. Dutt Santa Clara, CA Cisco (Systems/Technology)

All four are listed on the face of US 6,798,746 and on its parent, US 6,643,260. The patent is expressly "commonly owned" with the parent application (specification, Cross-Reference to Related Application), and the prosecuting firm of record is "Cisco Systems, Inc. – Patent Team" (FreePatentsOnline bibliographic record), confirming these were Cisco employee-inventors working under an obligation to assign.

Unusual patterns — none found. I found no evidence of a coordinated inventor departure near filing. To the contrary, the same inventor set kept filing Cisco continuation and sibling patents for years afterward:

  • Kloth + Edsall + Dutt + others filed the switch-port-analyzer family (e.g., US 7,474,666) and the CWDM mesh family (EP1668826) well into the mid-2000s (INPI data, Radaris inventor listings).
  • Kloth appears as a named Cisco inventor on applications dated 2003, 2005 and 2007.

This is the opposite of the "everyone left within 12 months" pre-fire-sale tell.

Contradiction flagged (literal reading required): The patent face states the parent, App. No. 09/213,105, was "filed on Dec. 18, 1999," while the specification text says it was "filed on Dec. 18, 1998," and Google Patents records the priority date as 1999-12-18. There is an internal one-year inconsistency in the document set. I am not correcting it; noting it only because it affects any priority-date calculation downstream.


Original assignee

  • Entity on the issued patent: Cisco Technology, Inc., San Jose, California.
  • Primary line of business: Networking hardware/software (routers, switches). This is a core operating company, not a holding vehicle.
  • Product embodying the claims: Yes, to a high degree of confidence. The patent describes hardware-implemented QoS classification, CAR/token-bucket rate limiting, and WRED output-queue scheduling for a switch/router ASIC — functionality that Cisco commercialized in its Catalyst/switch line (the specification even cites Cisco's own "Catalyst 8500 CSR Architecture" white paper and Lightstream 1010 materials as background). This is standard, ship-the-product Cisco R&D.
  • Current status: Operating. Cisco Systems, Inc. / Cisco Technology, Inc. remains an active, publicly traded operating company (NASDAQ: CSCO). No bankruptcy, dissolution, or acquisition.
  • Owner continuity: Google Patents lists Original Assignee = Cisco Technology Inc and Current Assignee = Cisco Technology Inc — i.e., the same entity. That equivalence is a strong indicator that no post-issuance assignment changed ownership.

Assignment timeline

Searches of Google Patents legal events, the issued-patent front page, US ODP/PEDS-derived records, and USPTO legacy-assignment PDFs surfaced no recorded post-issuance assignment for US 6,798,746 — no assignment, security interest, merger, change of name, license, or release naming any assignee other than Cisco Technology, Inc.

The record that logically exists (and that I can see the footprint of, but could not pin to a specific reel/frame in this session) is the original inventor→Cisco Technology, Inc. assignment taken at filing:

  • 2002 (contemporaneous with the 2002-05-28 continuation filing) / recorded 2002 — Reel unverified
    • Conveyance: Assignment (inventors → company)
    • Assignor: Raymond J. Kloth; Thomas J. Edsall; Michael Fine; Dinesh G. Dutt
    • Assignee: Cisco Technology, Inc., 170 West Tasman Drive, San Jose, CA 95134
    • Correspondent: Cisco Systems, Inc. – Patent Team (named "Attorney, Agent or Firm" on the published record; Cisco's in-house patent operation, which files the bulk of Cisco's assignment recordings). I cannot confirm a specific named attorney/firm of record for this filing-family reel without the Assignment Center page.
    • Context: routine employee invention assignment — no acquisition, no third party, no NPE.

No further entries. There is no assignment to an IP-holding LLC, no security agreement, no defensive aggregator, and no change of name in the chain. Under the task rule ("Many patents have no recorded post-issuance assignments — that is itself a finding"), the finding here is: the chain terminates at the original operating-company assignee.

Verification note: because I could not open the Assignment Center result grid, I cannot affirmatively distinguish "zero records beyond the original" from "records exist but did not surface in my web searches." The Google Patents Original-vs-Current assignee equality is the best available corroboration that nothing post-issuance was recorded.


Timeline diagram

timeline
    title Ownership of US 6798746
    1999 : Parent application filed
    2002 : Continuation filed
         : Inventors assign to Cisco Technology Inc
    2004 : Patent issued to Cisco Technology Inc
    2020 : Patent expires

NPE / troll-pattern signals

  1. Shell-entity transfer — Not present. No assignment to any "IP / Patents / Licensing / Holdings / Ventures" entity. Current assignee = original assignee = Cisco Technology, Inc. (Google Patents Original/Current assignee fields).

  2. Known asserter in the chain — Not present. Cisco Technology, Inc. appears on no NPE list (Acacia, Marathon, IV, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, etc.). It is a Fortune-100 operating company.

  3. Repeat correspondent across the chain — Not present / N-A. There is only one link in the chain (inventors → Cisco), recorded by Cisco's own in-house "/ Patent Team," so there is no recurrence across multiple links to point to. A single appearance by an in-house operating-company docketing group is not a signal.

  4. Cascading transfers — Not present. No consecutive assignments through chained LLCs; no transfers at all post-filing.

  5. Pre-litigation transfer — Not present. There is no assignment within 6 months of any suit, because (a) no post-issuance assignment is recorded and (b) no litigation naming this patent was found (see prior litigation section — zero affirmative indications).

  6. Bankruptcy fire-sale — Not present. Cisco has not filed Chapter 7/11; no proceedings-style bulk sale touching this patent.

  7. Privateering — Not present. No transfer from Cisco to any asserting NPE; no SEC-filing or EFF/Patent Progress coverage surfaced suggesting Cisco pushed this patent to an outside asserter.

  8. Defensive aggregator (anti-NPE) — Not present as an end state, but effectively neutralized by expiry. The chain never reached RPX, AST, LOT, Unified, or OIN; it simply ran out of term (adjusted expiration 2020-06-19).


Verdict

Operating-company assertion — but with the material qualifier that there is no litigation and the patent is expired, so the more precise characterization is insufficient-data-for-NPE / clean operating-company ownership with no assertion history.

Justification: The complete verified chain is Cisco Technology, Inc. → (no change), with Google Patents showing Original Assignee equal to Current Assignee and every sourced record (issued front page "Assignee: Cisco Technology, Inc."; FPO "Attorney, Agent, or Firm: Cisco Systems, Inc. – Patent Team") pointing to the same operating company. Cisco is a product-shipping networking vendor whose switch ASICs embody the claimed QoS/rate-limiting subject matter, and no assignment to any NPE or defensive aggregator is recorded and no suit naming US 6,798,746 was found. The only shortfall is evidentiary — I could not load the Assignment Center grid within this session's tool budget, so I am not claiming a verified "zero beyond the original assignment"; I flag the residual risk that a single routine inventor→Cisco reel/frame exists unread.

Verify at: https://assignmentcenter.uspto.gov/ (search by patent number 6798746) and the legacy index at https://assignment.uspto.gov/patent/index.html

Generated 10/1/2026, 3:01:22 PM

Prior art

Earlier patents, publications, and products that may anticipate or render the claims unpatentable.

✓ Generated

I'll research the prior art cited in US 6798746. Let me start with targeted searches.

Let me find the actual cited references on the patent's front page.

The citation table isn't surfacing. Let me try more targeted queries to reach the front-page references.

Prior Art Analysis — US Patent No. 6,798,746 B1

Scope, sources, and hard limits (read first)

Patent confirmed, not a similar number. USPTO/Google Patents bibliographic record: US 6,798,746 B1, "Method and apparatus for implementing a quality of service policy in a data communications network," Cisco Technology, Inc., inventors Kloth / Edsall / Fine / Dutt, priority 1999-12-18 (continuation of Ser. No. 09/213,105), filed 2002-05-28, granted 2004-09-28. Source: https://patents.google.com/patent/US6798746/en

What I could and could not retrieve. I located the patent's own front-page "US Patent References" (the references cited within 6798746) via the FreePatentsOnline record, https://www.freepatentsonline.com/6798746.html. That list was truncated at the reference spanning US 5,793,978 (and references below that number, plus any "Other Publications" / foreign references, were not returned in this session). Two consequences you must weigh:

  1. This is a list of references cited on the face of the patent — not a list of examiner § 102 rejections. A reference being listed means it was considered; it does not mean the examiner found it anticipatory. I could not retrieve the prosecution history (Form 892s / office actions) for 09/213,105 or 10/156,971, so I cannot tell you which of these were actually applied under § 102 versus § 103.
  2. I captured issue/publication dates only, not the underlying filing/priority dates. Anticipation analysis under pre-AIA § 102 turns on filing dates (for § 102(e)) and publication dates (for § 102(a)/(b)). Treat every § 102 claim-mapping below as preliminary.

Do not over-read the § 102 column. True anticipation requires a single reference disclosing every element of the claim. On the face of these references, my assessment is that none of the cited patents is a clean single-reference anticipation of any independent claim (1, 20, 35, 43, 46); they are best characterized as § 103 combinable art. I mark the few dependent claims where a single reference plausibly reads on the limitation.


I. Patent references cited in US 6,798,746

(As listed on the FPO front page; ordered as found. Issue dates as printed.)

1. US 6,643,260 B1 — Kloth et al., "Method and apparatus for implementing a quality of service policy in a data communications network," issued 2003-11-04, class 370/235.

  • Description: Same title and same inventive entity as the patent under analysis — this is the parent/related Cisco patent (the line that issued from the parent application).
  • § 102: Cannot anticipate claims 1–57. It is not "by another" and shares the same disclosure/inventive entity, so it is not prior art against 6798746. Listed as a related reference only.

2. US 6,335,932 B1 — Kadambi et al., "High performance self balancing low cost network switching architecture based on distributed hierarchical shared memory," issued 2002-01-01, class 370/391.

  • Description: Switch ASIC architecture using distributed hierarchical shared memory with per-port/per-flow buffering and packet memory management.
  • § 102: Relevant to the output-queue / buffering limitations of claims 1, 35, 43, 46 (queue selection, shared-memory queuing), but it does not disclose the CoS-assignment cascade or token-bucket CAR. No full anticipation.

3. US 6,275,494 B1 — Endo et al., "Packet switching system, packet switching network and packet switching method," issued 2001-08-14, class 370/395.52.

  • Description: Packet switch with priority/QoS class handling across a switching network.
  • § 102: Touches the "classify packet → priority → queue" elements of claims 1, 20, 35, 43, 46; not anticipatory standing alone.

4. US 6,167,445 — Gai et al., "Method and apparatus for defining and implementing high-level quality of service policies in computer networks," issued 2000-12-26, class 709/223.

  • Description: A policy framework that translates high-level administrator QoS policy into device-level configuration — directly on point for the patent's stated motivation ("QoS policy controlled by a network system administrator").
  • § 102: Relevant to the administrator-configurable ACE/policy limitations of claims 1, 20, 35, 43, 46; it is a policy-definition layer, not the per-packet hardware lookup, so no anticipation.

5. US 6,163,542 — Carr et al., "Virtual path shaping," issued 2000-12-19, class 370/399.

  • Description: Traffic shaping of ATM virtual paths.
  • § 102: Relevant to the contract value / committed rate / shaping limitations of claims 8, 11, 27, 29, 53–57. Shaping ≠ token-bucket policing; no anticipation.

6. US 6,157,613 — Watanabe et al., "Congestion control system for controlling congestion in switching cells," issued 2000-12-05, class 370/229.

  • Description: Congestion control with threshold-based cell dropping in a switch.
  • § 102: Directly relevant to the threshold-based / congestion dropping limitations of claims 5, 6, 7, 24, 25, 26, 55, 56; cell-based switching, so no full anticipation.

7. US 6,122,252 — Aimoto et al., "Packet switching device and cell transfer control method," issued 2000-09-19.

  • Description: Packet switch with cell transfer/QoS control.
  • § 102: Peripheral to claims 1, 20, 35, 43, 46; not anticipatory.

8. US 6,119,160 — Zhang et al., "Multiple-level internet protocol accounting," issued 2000-09-12, class 709/224.

  • Description: Multi-level IP accounting/statistics collection.
  • § 102: Relevant to the per-flow statistics/byte-count accounting limitations underlying claims 1, 16, 42 (port/flow statistics), not to the QoS decision itself.

9. US 6,104,700 — Haddock et al., "Policy based quality of service," issued 2000-08-15.

  • Description: Rule/policy-based QoS applied to classified traffic — a strong conceptual match to the ACE→codepoint→queue pipeline.
  • § 102: The most substantive policy-classification reference for claims 1, 20, 35, 43, 46; still not a single-reference anticipation of the MAC-DA/ACE CoS cascade plus CAM flow table.

10. US 6,094,435 — Hoffman et al., "System and method for a quality of service in a multi-layer network element," issued 2000-07-25, class 370/414.

  • Description: QoS in a multi-layer network element (L2/L3/L4-aware queuing and prioritization) — the closest structural analogue to the patent's L2/L3/L4 flow handling.
  • § 102: Strong reference for the multi-layer flow classification + output-queue/threshold elements of claims 1, 2, 20, 21, 35, 43, 46, 48, 49. Best § 103 candidate; I do not read it as a complete § 102 anticipation.

11. US 6,047,326 — Kikki, "Accounting system and method for a nominal bit rate network service," issued 2000-04-04, class 709/228.

  • Description: Nominal-bit-rate accounting/rate control.
  • § 102: Relevant to rate/contract limitations of claims 8, 11, 53; not anticipatory.

12. US 6,035,281 — Crosskey et al., "System and method of multiparty billing for Web access," issued 2000-03-07, class 705/14.

  • Description: Multiparty billing for web access.
  • § 102: Weak. Billing/accounting only — bears at most on the general notion of service-based charging. Not anticipatory of any claim.

13. US 5,970,477 — Roden, "Method and system for allocating costs in a distributed computing network," issued 1999-10-19, class 705/32.

  • § 102: Weak, accounting/cost-allocation. Not anticipatory.

14. US 5,959,990 — Frantz et al., "VLAN frame format," issued 1999-09-28, class 370/392 (Cisco).

  • Description: VLAN-tagged frame format — relevant to the tag/CoS-in-frame and trunk/access-port handling.
  • § 102: Relevant to the frame/CoS-field and trunk-vs-access-port aspects of claims 1, 20, 35, 43, 46; a frame-format patent cannot anticipate the QoS method.

15. US 5,926,458 — Yin, "Method and apparatus for servicing multiple queues," issued 1999-07-20, class 370/230.

  • Description: Servicing multiple output queues.
  • § 102: Relevant to the plurality of output queues / queue-selection elements of claims 1, 2, 22, 35, 43, 46, 48, 49.

16. US 5,922,051 — Sidey, "System and method for traffic management in a network management system," issued 1999-07-13, class 709/223.

  • § 102: Traffic-management context only — peripheral to claims 1, 20; not anticipatory.

17. US 5,841,874 — Kempke et al., "Ternary CAM memory architecture and methodology," issued 1998-11-24, class 380/50.

  • Description: Ternary CAM architecture (the "don't care"/masking hardware).
  • § 102: Relevant to the TCAM limitation of claim 17 ("using a TCAM to store said active flow table"), claim 47 ("said CAM is a ternary CAM"), and the per-entry programmable mask of claim 51. A memory-architecture reference cannot anticipate a QoS system claim on its own, but it is the leading § 102/§ 103 reference for the TCAM breadth of claims 17/47/51.

18. US 5,838,683 — Corley et al., "Distributed interactive multimedia system architecture," issued 1998-11-17, class 370/408.

  • § 102: Multimedia distribution context; weak. Not anticipatory.

19. US 5,835,727 — Wong et al., "Method and apparatus for controlling access to services within a computer network," issued 1998-11-10, class 709/238.

  • Description: Access control to network services.
  • § 102: Relevant to the access-control / ACE-style filtering limitations (claims 1, 20, 35, 43, 46), not to the queue/token-bucket pipeline.

20. US 5,835,494 — Hughes et al., "Multi-level rate scheduler," issued 1998-11-10, class 370/397.

  • § 102: Relevant to multi-level rate scheduling limitations of claims 1, 8, 11, 35, 53; not anticipatory.

21. US 5,828,653 — Goss, "Quality of service priority subclasses," issued 1998-10-27, class 370/230.

  • Description: QoS priority subclasses — i.e., multiple service levels within a class.
  • § 102: Relevant to the priority-level / subclass → queue/threshold limitations of claims 1, 2, 20, 21, 22, 35, 43, 46, 48, 49. Notable conceptual reference; not a complete anticipation.

22. US 5,805,595 — Sharper et al., "System and method for communicating packetized data over a channel bank," issued 1998-09-08, class 370/422.

  • § 102: Channel-bank data transport; peripheral. Not anticipatory.

23. US 5,793,978 — (title/details not captured — the FPO list truncated at this entry). Entry exists on the front page; I could not retrieve its title, date, or class in this session, and I will not guess at it. The remaining references below 5,793,978 and any "Other Publications" / foreign references were likewise not retrievable here.


II. Overall § 102 assessment (and how it connects to the earlier sections)

  • No cited reference is a strong single-reference § 102 anticipation of an independent claim. The independent claims (1, 20, 35, 43, 46) each require a combination — (a) port-/MAC-DA-/ACE-driven CoS assignment cascade, plus (b) a CAM/active-flow-table lookup of QoS parameters, plus (c) codepoint-driven output-queue selection, plus in some claims (d) aggregate-flow CAM indexing. The cited set splits across those pieces: Gai '445 / Haddock '700 (policy/ACE), Hoffman '435 / Goss '653 (multi-layer QoS / priority subclasses), Yin '458 (multiple queues), Frantz '990 (VLAN/CoS frame), Kempke '874 (TCAM). That is a § 103 fact pattern, not a § 102 one.
  • Dependent claims most exposed to a single reference (limitation-level only, and only if the parent claim's elements are also met): claim 17 / 47 / 51 (TCAM, ternary CAM, programmable per-entry mask) → Kempke '874; claims 5–7 / 24–26 / 55–56 (threshold/WRED-like dropping) → Watanabe '613.
  • Consistency check with the prior sections. This aligns with — and sharpens — the earlier Strategic summary, which flagged "§ 103 obviousness over 1990s QoS/flow-classification art (token bucket, WRED, TCAM/ACL-based classification, per-flow queue selection)" as the realistic attack vector. The front-page list confirms those exact categories exist as cited art. No contradiction with the earlier litigation or PTAB sections was found; those sections correctly note no IPR/reexam has ever applied any of this art to 6798746, so all 57 claims remain untested.

III. What I would verify next (to make the § 102 calls defensible)

  1. Pull the filing/priority dates for each reference above (especially US 6,335,932, US 6,275,494, US 6,167,445, US 6,094,435) from PatentCenter/Espacenet, to test pre-AIA § 102(e) eligibility against the 1999-12-18 priority date.
  2. Retrieve the complete Form 892 / examiner citations and any § 102 vs. § 103 rejections from the file histories of 09/213,105 and 10/156,971 (surfacing which of these references the examiner actually applied, and to which claims) — this is the authoritative substitute for my inference-level mapping.
  3. Capture the truncated references (US 5,793,978 and below) plus any non-patent literature, which my search did not return.
  4. Independently confirm the Kempke '874 and Hoffman '435 teachings against claims 17/47/51 and 1/2/48/49 respectively, as the two highest-value single-reference reads.

Bottom line: The relevant art for US 6,798,746 is a mid-to-late-1990s Cisco/telecom QoS corpus — policy-based classification (Gai '445, Haddock '700), multi-layer QoS queuing (Hoffman '435, Goss '653, Yin '458), VLAN/CoS framing (Frantz '990), congestion/threshold dropping (Watanabe '613), rate shaping (Carr '542, Hughes '494, Kikki '326), and ternary CAM hardware (Kempke '874). My § 102 mapping is preliminary and limitation-level only; the honest characterization is that this art supports a § 103 obviousness theory far more than it supports single-reference anticipation of any independent claim.

Generated 10/1/2026, 3:01:50 PM

Obviousness

Combinations of prior art that suggest the claimed invention would have been obvious under 35 U.S.C. § 103.

✓ Generated

I'll gather the prior-art references associated with this patent (the page's "Prior Art"/citations data) before building the § 103 analysis.

Obviousness Analysis — U.S. Patent No. 6,798,746 under 35 U.S.C. § 103

0. Scope and relationship to the prior sections

The earlier sections established: assignee Cisco Technology, Inc.; inventors Kloth, Edsall, Fine, Dutt; 57 claims, none ever construed or canceled; no PTAB activity; no litigation found. Because nothing has been tested, this § 103 analysis is a first-principles one — there is no prosecution disclaimer, no IPR FWD, and no court construction to lean on. That cuts both ways (see § 8).

1. What the "Prior Art section of this page" actually contains — and an important limitation

I must be explicit here, because the strict "do not fabricate" rule applies most sharply to prior-art citations.

The page text supplied to me does not include the patent's "Citations / References Cited" list (the examiner- and applicant-cited U.S. patents and NPL). What it does contain in the prior-art data fields is:

So the page's own prior-art data is insufficient on its face to build a § 103 case, and I have supplemented it with live searches (§ 3). I flag this rather than pretend a citations list exists.

Flagged contradiction (date). The Google Patents record and the printed patent (ISD, col. 1) state the parent, application 09/213,105, was filed Dec. 18, 1999, and give a priority date of 1999-12-18 — consistent with the earlier Litigation/PTAB sections. But the sibling continuation US 6,868,065 (same inventors, same parent) states the parent 09/213,105 was filed "on Dec. 18, 1998" (https://patentimages.storage.googleapis.com/14/72/b9/84c20997b1f406/US6868065.pdf). I am not auto-correcting either date. The discrepancy matters: it shifts the pre-AIA § 102(b) critical date by a full year (see § 3, note on RFC 2474/2475).

2. Person of ordinary skill in the art (POSITA)

A POSITA at the 1998–1999 priority date would hold a B.S. in EE/CS plus ~2–4 years in packet-switched networking, and would be familiar with: (a) IP header fields (ToS/DS, protocol, addresses, L4 ports); (b) IEEE 802.1Q/p VLAN tagging and the 3-bit priority ("CoS") field; (c) ACL-based packet classification and CAM/TCAM hardware lookups; (d) token-bucket/leaky-bucket policing; and (e) RED/WRED queue management. The patent's own specification concedes the last three are well known — it states token-bucket algorithms and WRED are "well known to those of ordinary skill in the art," and that CAMs/TCAMs are "well known" (US6798746, "Detailed Implementation"). Those concessions do substantial § 103 work here.

3. Candidate reference set (verified via search unless noted)

Ref Subject matter relied on Status/date Source
US 6,091,725 (Cheriton & Bechtolsheim, Cisco) Processing datagrams as separate flows based on the source-destination address pair; per-flow traffic management, prioritization, access control; per-flow buffer/bandwidth resource assignment, varied with congestion Filed Dec. 29, 1995; issued Jul. 18, 2000 → § 102(e) art https://www.docketalarm.com/cases/PTAB/IPR2019-01292/...Exhibit-1057-59-US_Pat_No_6,091,725.pdf
US 6,449,647 / US 6,006,264 / WO 99/06913 (Cisco/ArrowPoint) Flow classification associating priority codes / QoS classes with flows "based on IP addresses and other inner protocol header fields"; aggregation of flows into "flow pipes" with reserved bandwidth; per-flow QoS tags Priority Aug. 1, 1997; WO published Feb. 11, 1999 → § 102(a)/(b) publication; US 6,006,264 filed Mar. 30, 1998 https://patentimages.storage.googleapis.com/ef/24/c4/daafde757ba278/US6449647.pdf ; https://lexdana.ai/patent/[6449647](/patent/6449647)
Srinivasan et al., "Fast and Scalable Layer Four Switching," ACM SIGCOMM '98 Best-matching filter among many "to classify packets into QoS-classes"; multi-field classification 1998 printed publication Quoted in EP 0 993 153 B1 spec, https://patentimages.storage.googleapis.com/6a/16/ce/4204efb887de9d/EP0993153B1.pdf
IEEE 802.1Q / 802.1p (1998) 3-bit priority/CoS field in tagged frames; access vs. trunk port handling and per-port default priority 1998 standard General knowledge (not re-verified live this session)
RFC 2474 (Nichols et al., Dec. 1998) and RFC 2475 (Blake et al., Dec. 1998) The DS field replacing ToS; codepoint → per-hop behavior Dec. 1998 General knowledge (EP0993153B1 cites RFC 2475 as "prior art 4")
Floyd & Jacobson, "Random Early Detection Gateways for Congestion Avoidance," IEEE/ACM ToN (Aug. 1993) RED; basis for WRED and multi-threshold drop probabilities 1993 General knowledge; WRED mechanics also described as conventional in later patents (https://patents.justia.com/patent/[7197244](/patent/7197244))
Turner, "New Directions in Communications…," IEEE Comm. Mag. (1986) Token/leaky bucket rate regulation 1986 General knowledge; conceded "well known" in the '746 spec

Uncertainty marker: I could not independently re-verify the exact bibliographic details of the two RFCs, the 802.1Q clause numbers, Floyd & Jacobson, or Turner in this session; they are stated from well-established knowledge and should be confirmed against a library before being filed.

4. The independent claims, reduced to elements

  • Claim 1 — (1) receive IP packet at a port; (2) extract flow info; (3) three-step CoS classification: port CoS → MAC-DA CoS → ACE-matched CoS; (4) use flow info as index into an active flow table for QoS parameters; (5) derive a codepoint; (6) direct to output queue per codepoint.
  • Claim 20 — same preamble; flow info matched against a CAM entry in an aggregate flow table (each entry = aggregation of flows); select output queue from the match.
  • Claim 35 — apparatus: input, flow-info extractor, IP packet modifier performing the three-step classification, active flow table with QoS params, codepoint generator, multiple output queues.
  • Claim 43 / 46 — apparatus: CAM + aggregate flow table, CAM entries indexing QoS parameters; claim 46 CAM matches to a "preconfigured aggregate flow entry" holding an index.

5. Ground 1 — Claims 1–19 over Cheriton + Srinivasan + 802.1Q + token bucket + RED/WRED

Combination: US 6,091,725 as primary; Srinivasan '98 and IEEE 802.1Q for the classification layer; Turner (or RFC 1633's token bucket) and Floyd & Jacobson for limitation (4)–(6) refinements.

  • Cheriton discloses receiving datagrams and processing them "as separate flows, based on the source-destination address pair" and controlling "the amount of buffer resources and bandwidth resources assigned to each flow… individually… by network management," including access control — i.e., a per-flow table holding per-flow QoS/resource parameters, indexed by extracted flow information. That is limitations (1), (2), (4), and the seed of (6).
  • Srinivasan '98 supplies using extracted multi-field flow information in a best-match filter lookup to classify packets into QoS classes — the "compare flow information with configured Access Control Entries… reassign CoS" limitation, implemented in the same ACL/TCAM hardware the '746 specification concedes is conventional.
  • IEEE 802.1Q supplies the CoS field in tagged frames and the trunk vs. access port dichotomy that limitation (3) presupposes; per-port default priority is a standard switch configuration knob. The MAC-DA step is a routine administrative mapping layered on the same priority mechanism.
  • RFC 2474 supplies the DS "codepoint" as the internal QoS label from which the written field is derived — limitation (5).

Motivation: The '746 background itself states the problem — "routers have, in the past, kept packet counts and rate limited packets in software, but router software has not scaled." Cheriton already teaches doing per-flow management in the network device; Srinivasan teaches doing multi-field classification at wire speed in hardware; 802.1Q and RFC 2474 teach the standardized fields to carry the result. A POSITA seeking administrator-controlled, line-rate QoS (the stated goal) had every reason to combine them, and KSR v. Teleflex, 550 U.S. 398 (2007), makes this a textbook predictable combination of known elements yielding the expected result.

Dependent claims: claim 7 (WRED) → Floyd & Jacobson; claims 8/11 (token bucket w/ contract value and leak rate) → Turner + spec's own admission; claims 3/4/18/19 (L2/L4 flow info in the table) → Srinivasan's multi-field classifier; claim 16 (auto-create entry for new flow) → Cheriton's per-flow state creation; claim 17 (TCAM) → Srinivasan + admitted TCAM knowledge. Claims 12–14 (drop / random-drop / modify out-of-profile) are the three listed options in any policing scheme and are explicitly enumerated in the '746 spec.

6. Ground 2 — Claims 20–34 over Srinivasan + US 6,006,264/6,449,647 + Cheriton + token bucket

Combination: Srinivasan '98 (CAM/ACL best-match against masked multi-field entries) + the ArrowPoint family (aggregating flows into higher-level groupings — "flow pipes" — each with reserved bandwidth) + Cheriton (per-flow counters/rate control) to reach the aggregate flow table claim.

  • Claim 20's "CAM containing entries each corresponding to an aggregation of individual flows" is met by the combination of an ACL-style masked CAM (Srinivasan) with the express flow-aggregation teaching of US 6,006,264/6,449,647 ("Individual flows are aggregated into pipes"; flows in one pipe share QoS characteristics) and its WO 99/06913 publication — the latter squarely § 102(a)/(b) art.
  • Claims 22/24/25/26 (queue threshold + drop behavior for the aggregate) → Fl

Generated 10/1/2026, 3:01:54 PM

Extensions

Patent term adjustments, term extensions, continuations, divisionals, family members, and expiration dates.

Log in to generate
Not generated yet. Log in to request this analysis.

Derivative works

Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.

Log in to generate
Not generated yet. Log in to request this analysis.

Keep exploring

Other patents in Software Technology & Computing Systems (T)

See all Software Technology & Computing Systems (T) patents →