US 6633560

I'll search for the patent and check for any 2026 CAFC docket activity.

Let me check for litigation history, PTAB proceedings, and the full claim set.

US Patent 6,633,560 — Analyst Summary

Scope note up front: I ran searches against Google Patents (which mirrors the USPTO full-text record), USPTO-report/PTAB sources, and CAFC/litigation databases. I found the patent record itself without difficulty. I did not find any CAFC 2026 docket entry, PTAB proceeding, or district-court case tied to this patent number, and I could not retrieve the full printed claim set from an authoritative full-text source in this session — only claims 1–3, from a secondary aggregator. Details and confidence flags below.

---

1. Bibliographic data

---

2. Abstract (verbatim from the patent record)

"A system and method are described for partitioning a network service among a plurality of service managers. The method includes configuring a first service manager to send a first request to a forwarding agent for packets meeting a first criteria and sending the first request to the forwarding agent. A second service manager is configured to send requests to the forwarding agent for packets meeting a second criteria and the second request is sent to the forwarding agent. Packets are checked at the forwarding agent to determine whether the packets meet the first criteria or the second criteria and packets that meet the first criteria are received at the first service manager; and packets that meet the second criteria are received at the second service manager."

---

3. Plain-language overview of the independent claims

Claim 1 — verified text (secondary source; see caveat)

Claim 1 as reproduced by an aggregator (Trustoria, which republishes USPTO claim text) reads, in plain terms:

A method of partitioning a network service among multiple service managers, comprising:

1. receiving a first portion of a traffic flow at a first forwarding agent, the traffic flow coming from a network and initiated by one or more clients;
2. receiving a second portion of that traffic flow at a second forwarding agent;
3. checking packets at the forwarding agents to determine whether they meet a first criteria or a second criteria;
4. processing the packets based on that determination in order to direct one or more packets to a selected one of a plurality of servers; and
5. receiving instructions from a first service manager at the first forwarding agent, the instructions including an affinity key indicating how to manage selected packets, which the service manager uses to identify which flows should propagate through the first forwarding agent — the affinity key including one or more of: source IP address; destination IP address; source port number; destination port number; and protocol identification.

In everyday language: instead of one load balancer sitting in the wire, you spread the job across multiple forwarding agents (typically routers) and multiple "service managers" (the brains). A single logical traffic flow can arrive at more than one router, and the routers classify packets by criteria and steer them toward a chosen backend server, following "affinity key" instructions pushed down by a service manager.

Caveats on this claim text: (a) It came from a third-party republisher, not directly from USPTO full text in this session; (b) the source contains an obvious OCR artifact ("affinity kev"), which I have not auto-corrected per your instruction — the real term is presumably "key"; (c) the claim uses the phrase "a group of elements consisting of" with "a selected one or more of," a formulation worth verifying against the printed patent. Note also this issued claim 1 is narrower in wording than both the abstract and the specification's summary paragraph, which speak of "configuring a first service manager to send a first request…" — the issued claim instead recites two forwarding agents, packet checking, directing to a selected server, and affinity-key instructions. That is consistent with amendment during prosecution and is worth flagging if claim scope matters.

Dependent claims 2–3 (verified text)

• Claim 2 adds that packets meeting the first criteria are received at the first service manager and packets meeting the second criteria are received at a second service manager, with each service manager coupled to both forwarding agents — i.e., the partitioning of the client/flow population across managers.
• Claim 3 adds that each forwarding agent encapsulates the packets matching its criteria before communicating them to the respective service manager.

Other independent claims — likely present, NOT verified

The patent's "Summary of the Invention" and abstract describe at least three additional claimed subject matters, which in this family typically appear as separate independent claims (apparatus and method claims):

• A forwarding agent apparatus — "a service manager receiving interface configured to receive a plurality of requests from a plurality of service managers for packets meeting a plurality of criteria; a network interface configured to receive packets from devices on a network; a processor configured to check the packets against the criteria; and a service manager sending interface configured to send matching packets to the corresponding service manager."
• A method of handling packets — receiving multiple requests from multiple service managers for packets meeting multiple criteria, receiving packets from the network, checking the packets, and sending matching packets to the corresponding service manager.
• A service manager configured to send a wildcard affinity update packet — containing a wildcard affinity specifying a set of source IP addresses, a set of destination IP addresses, a time-to-live, and instructions that a matching packet be sent to the service manager.

I am flagging these as unverified. They are drawn from the specification summary language, and I could not confirm the exact issued claim wording, numbering, or which of them are truly independent. Do not rely on their phrasing without checking the printed claims.

---

4. What the invention actually does (specification-level context)

• The problem: traditional network service appliances (load balancers, firewalls, NAT, proxies) must be physically inserted in the data path — a scalability bottleneck and a single point of failure.
• The solution: split "control plane" from "forwarding plane." Service managers make decisions; forwarding agents — implemented on existing routers/switches — execute instructions.
• Wildcard affinities are multicast by service managers to register interest in classes of flows (e.g., a virtual IP / cluster address plus port, with source and destination netmasks). Fixed affinities are unicast to install per-flow instructions, overriding the wildcard, and are keyed by a 5-tuple (source/destination IP, source/destination port, protocol).
• A pair of wildcard affinities (inbound and outbound) is typically sent; outbound wildcards differ depending on whether traffic is dispatched (server replies with the virtual IP) or directed via NAT (server replies with its real IP), per Figs. 13A–13B.
• Messages between managers and agents use a defined service-message format (UDP), including affinity update, affinity update-deny, interest match, and IP-packet-only messages, with segments for NAT actions, sequence-number adjustment, advertise, interest criteria, and action lists.
• The key point of this patent: multiple service managers share the same set of forwarding agents, partitioning the client/flow population without any client reconfiguration ("without client involvement"), with the assignment controlled centrally at the managers via wildcards.

---

5. Docket / litigation status

• CAFC 2026 dockets: No 2026 Federal Circuit appeal involving US 6,633,560 surfaced in my searches. Treat this as "not found," not as certified absence — my search tools returned an empty result set for the targeted query.
• PTAB / district court: My searches surfaced Cisco litigation activity generally (e.g., Monarch Networking Solutions v. Cisco, Finjan v. Cisco, Telcordia v. Cisco, Commil v. Cisco), but none of those cases involved US 6,633,560 as an asserted patent. The Telcordia and Commil cases involve entirely different patents (the '763/'633 reissue, and Commil's wireless patents, respectively).
• Practical consequence: With a 20-year term from the July 2, 1999 filing, this patent expired July 2, 2019, which is consistent with the "Expired – Lifetime" status and makes present-day active enforcement essentially unavailable.

---

6. Identifier-collision warnings (important)

Because you asked for results for 6,633,560 specifically and no similar numbers, note these distinct, unrelated records that a loose search for "6633560" will pull in:

• JP 6633560 B2 — a 2020 Japanese patent to Yazaki for a "Ground fault detector" using a flying-capacitor scheme. Completely unrelated to the US patent. Do not conflate.
• US 8,813,663 — a seed-delivery/seeding-machine patent litigated in IPR2019-01044 (Precision Planting/AGCO v. Deere). Different number, different art.
• US 2002/0141401 A1, "Distributing packets among multiple tiers of network appliances," uses the same figure-reference convention (service manager 300, host 306/308) and appears related to this patent family — but it is a separate application/publication and is not the patent you asked about.

---

7. Uncertainty summary

Recommended next step for a definitive answer: pull the claim set directly from USPTO Patent Center / Patent Public Search (or the granted-PDF at patentimages.storage.googleapis.com) rather than relying on the republished text I retrieved.

I'll research litigation involving US patent 6633560 using patent litigation sources.

Let me refine the search to focus specifically on litigation databases for this exact patent number.

Litigation Search Results: US Patent 6,633,560

Summary: No litigation involving U.S. Patent No. 6,633,560 was found in the sources searched.

What I searched

I ran searches targeting patent-litigation databases (including the Unified Patents litigation portal format at portal.unifiedpatents.com/litigation/caselist, PACER/Justia/CourtListener dockets, and general CAFC/district-court coverage) using the literal identifiers 6633560, 6,633,560, and combinations with the assignee (Cisco) and the subject matter (load balancing / forwarding agents). I found no case records naming US 6,633,560 as a patent-in-suit, and no PTAB proceedings (IPR/PGR/CBM) against it.

Important caveats on the negative result

1. The searches returned substantial noise from similarly numbered but distinct patents. To be clear about what these are not (so the negative result isn't confused with them):
   • U.S. Patent No. 6,816,356 — Presidio Components v. American Technical Ceramics (S.D. Cal., e.g., No. 3:14-cv-02061; Fed. Cir. appeal). This is the "Integrated Broadband Ceramic Capacitor Array" patent — a different patent.
   • U.S. Reissue Patent No. Re. 36,633 — asserted in Telcordia Technologies, Inc. v. Cisco Systems, Inc. (D. Del. No. 1:04-cv-00876). Different patent number.
   • U.S. Patent No. 6,683,858 — Paltalk Holdings, Inc. v. WebEx Communications, Inc., et al. (W.D. Tex. No. 6:21-cv-00757). Different patent number.
   • JP Patent No. 6633560 B2 — a Japanese ground-fault detector (Yazaki). Same digits, different jurisdiction/numbering scheme — not a US patent litigation.
2. 6,633,560 is a Cisco-owned patent. It issued 2003-10-14, was filed 1999-07-02, and (per the Google Patents record) reached its anticipated expiration on 2019-07-02, with legal status "Expired – Lifetime." This makes it an unlikely candidate for a past assertion campaign, and the multi-defendant NPE suits I did encounter (e.g., Portsmouth Network Corp. v. Cisco, E.D. Tex. No. 2:23-cv-00441; Enhanced Data Streaming LLC v. Cisco, E.D. Tex. No. 2:25-cv-01038) assert different patents and are Cisco-as-defendant cases unrelated to the '560 patent.
3. Limitations of my search. I could not directly query the Unified Patents litigation portal's index for this specific patent (the search engine returned the portal's general framework pages rather than a case list for 6633560), and I was not able to run a verified PACER docket query. My conclusion is therefore "no litigation found in the sources searched," not an affirmative representation that none exists.

Recommendation before relying on this

To convert this into a definitive litigation clearance, I would recommend a direct query of:

• Unified Patents Portal — https://portal.unifiedpatents.com/litigation/caselist?patents=6633560 and the corresponding PTAB list .../ptab/caselist?patents=6633560
• PACER / Docket Alarm / Lex Machina for district-court and appellate dockets
• USPTO Patent Trial and Appeal Board (IPR/PGR/CBM) and USPTO Assignment records to confirm no ownership transfers that might have spawned assertions

If you'd like, once I can access a portal index directly, I can populate a case-by-case table (plaintiff, defendant, jurisdiction, case number, filing date, status). Based strictly on the searches performed so far, I should state explicitly: I do not have high-confidence knowledge of any litigation involving US 6,633,560, and the searches conducted found none.

I'll start by checking whether any PTAB proceedings exist beyond the (empty) ODP record.

The generic searches are returning same-numbered but unrelated patents. Let me target the actual patent and known litigation context.

Results show only unrelated same-numbered patents. Let me search PTAB dockets directly.

Proceedings overview

Total AIA trial proceedings on file: 0. The structured PTAB source provided in this task (USPTO Open Data Portal) returns no IPR, PGR, or CBM proceedings for US 6,633,560 as of the most recent ODP ingest, and my independent web searching surfaced no petition, institution decision, Final Written Decision, or Federal Circuit appeal matching this patent. With zero proceedings, there is no "claims invalidated / claims sustained / settled / institution denied" breakdown to report — the patent is untested at the PTAB, which is a materially different defensive posture from either "hardened by surviving IPRs" or "claim 1 is dead." The more consequential fact for a defendant is not the empty PTAB docket but the expiration entry on the face of the structured data: anticipated expiration 2019-07-02, legal status "Expired - Lifetime."

Search diligence and negative results (flagged for transparency)

Because the task instructed me to flag anything the ODP may not have indexed, I searched for proceedings tied to this patent by number and by subject matter. What came back were same-numbered but unrelated patents, which I am explicitly not attributing to US 6,633,560:

• U.S. Patent 4,134,560 (helicopter controller, "locking means") — district-court infringement opinion, unrelated.
• U.S. Patent 6,915,560 (Austin) — claim-construction appendix, unrelated.
• U.S. Patent 10,129,590 and a "'560 Application" in IPR2024-00906 and IPR2025-00429 — exercise-equipment and bandwidth-allocation proceedings, unrelated.
• IPR2025-00429, Cisco Systems, Inc. v. WSOU Investments, LLC re U.S. 9,450,884 — Cisco appearing as petitioner against a third party's patent. Not a challenge to the '560 patent.

⚠️ Caveat: my tooling was truncated mid-search (the session hit a step limit while running PTAB-specific queries). I therefore cannot claim to have executed an exhaustive, line-by-line sweep of PTAB E2E. What I can say is that nothing in the structured ODP data, and nothing surfaced by search, evidences an AIA trial against US 6,633,560. I found no ex parte reexamination either, but I could not verify that exhaustively. Treat "no PTAB activity on file" as the operating conclusion, not a certified negative.

Proceedings by proceeding

None. There is nothing to list. I will not manufacture a proceeding number, petitioner, panel, or FWD verdict — the instructions forbid it and, more practically, a fabricated IPR would be catastrophic in a defendant's hands. If the ODP ingest later populates a proceeding, the analyses to run are the standard ones (claim-level FWD outcomes, § 315(e)(2) estoppel scope, General Plastic / Fintiv posture).

Strategic summary

Claim status: all claims UNTESTED, not canceled. Every claim of US 6,633,560 — including independent claim 1 ("A method of partitioning a network service among a plurality of service managers…"), and the dependent claims recited in the patent (e.g., claim 2's first/second service-manager coupling limitation and claim 3's encapsulation limitation) — stands as issued, never having been construed or canceled by the Board. There is no IPR-narrowed claim set, no certificate canceling claims, and no surviving-claims list to construct. The patent's operative narrowing is temporal, not adjudicative: it expired 2019-07-02 per the structured record ("Anticipated expiration," status "Expired - Lifetime").

Estoppel landscape: nothing to work with, which cuts both ways. Because no IPR or PGR was ever instituted, no one is subject to § 315(e)(2) estoppel on this patent, and there is no petitioner-privity chain to trace. Practically, that means a defendant today faces no estoppel-based constraint — every § 102/§ 103 ground that could have been raised is still available, and there is no prior PTAB record to trigger § 325(d) discretionary denial or Advanced Bionics estoppel-by-prosecution arguments. Conversely, there is no prior winning invalidity theory to borrow: any IPR would be built from scratch, and the Board's current institution climate is markedly tighter than in the 2013–2020 period when an obvious IPR candidate like this would typically have drawn a challenge. Note that even an expired patent remains a permissible IPR target (claims can still be canceled), but a patent owner can no longer meaningfully amend — the review would be a pure validity referendum with no amendment escape valve.

Pattern signals: none. There is no repeat petitioner (no petitioner at all), no patent-owner appeal practice to infer, and no defensive aggregator in the chain — I found no Unified Patents, RPX, or similar entity involvement. The patent owner of record is Cisco Technology, Inc., the operating-company assignee, with the original July 1999 filing and a 1999-10-04 assignment recorded from the nine named inventors (Albert, Howes, Jordan, Kersey, LeBlanc, Menditto, O'Rourke, Tiwari, Tsang). This is not a patent that has circulated through monetization vehicles.

Recommended next steps

1. If you are a defendant receiving a demand today, lead with expiration and § 286, not with the PTAB. The structured record shows expiration on 2019-07-02 and status "Expired - Lifetime" (https://patents.google.com/patent/US6633560/en). Under 35 U.S.C. § 286, damages reach back only six years from filing; a suit filed on or after 2025-07-02 would have a lookback window beginning entirely after the patent expired, leaving no recoverable pre-expiration damages period. Any demand letter asserting live royalties on this patent should be pressed hard on that point.
2. Verify the negative on the official dockets before you rely on it in a brief. Check PTAB E2E / PTAB Center (https://ptacts.uspto.gov/ptacts/) and the patent's USPTO PatentCenter transaction history, and cross-check CourtListener (https://www.courtlistener.com/) for any district-court or Federal Circuit docket naming US 6,633,560. My search coverage was truncated, so treat this as a diligence task, not a completed one.
3. Do not build an argument on an absent proceeding. There is no FWD to quote and no disposition to link. If opposing counsel claims the patent was "upheld by the PTAB," that is unsupported by the record I can see — the patent was never before the Board.
4. If you are considering filing an IPR (e.g., as a defensive counterweight to a revived assertion), budget for a from-scratch petition with no § 315(b) clock concerns and no Fintiv parallel-litigation overlay until a district case exists — but weigh it against step 1: for an expired patent with a likely empty damages window, an IPR is usually an expensive way to buy a defense you may already have.

Bottom line: the absence of PTAB activity here is not the "well-asserted patents eventually attract IPRs" signal — it is best explained by a 1999-era Cisco patent that expired in 2019 and never became a contested assertion target in the AIA era. Nothing on the PTAB record helps or hurts a defendant; the expiration date does.

I'll research the assignment chain for US 6633560 before writing anything.

Let me check the USPTO/report mirrors and any litigation or transfer history.

Let me try to pin down the initial assignment reel/frame and check for any assertion history.

US 6633560 B1 — Ownership Reconstruction

Patent: Distribution of network services among multiple service managers without client involvement
App. No.: 09/347,126 · Filed: 1999-07-02 · Issued: 2003-10-14 · Assignee of record: Cisco Technology, Inc.
Sources reached: Google Patents legal events (https://patents.google.com/patent/US6633560/en), uspto.report grant page, Trustoria inventor/assignee mirrors, patentleaderboard.com. USPTO Assignment Center / legacy assignment (reel-frame) records could NOT be retrieved in this session — see caveat in the Assignment timeline section.

Inventors

All nine named inventors appear on the face of the patent:

Pattern notes:

• The residences cluster tightly on two Cisco engineering sites (Research Triangle Park, NC and metro Atlanta, GA), which is consistent with a single-company development team rather than a distributed group of independents.
• The application is one of a 13-application family filed the same day (1999-07-02), all cross-referenced in the "Cross Reference to Related Applications" section (e.g., Ser. Nos. 09/346,634; 09/347,124; 09/347,111; 09/347,428; 09/347,122; 09/347,108; 09/347,034; 09/347,048; 09/347,125; 09/347,123; 09/347,109; 09/347,036). This is a coordinated corporate filing campaign, which is inconsistent with the "inventors leave and take their portfolio" fire-sale precursor pattern.
• Departure pattern: not determinable. I found no employment-tenure data for any inventor. I will not infer departures from the absence of evidence.

Original assignee

Cisco Technology, Inc. (San Jose, CA) — the wholly-owned Cisco Systems IP-holding subsidiary, and the assignee of record on essentially all Cisco patents of this era. The patent lists "Cisco Technology Inc" as both original and current assignee.

• Primary line of business: data networking equipment and software (routers, switches, content/load-balancing products).
• Product embodiment: the claims describe distributing a network service (load balancing, filtering, NAT) across forwarding agents embedded in routers, coordinated by service managers — the architectural basis for Cisco's content-switching/load-balancing line (contemporaneously, LocalDirector and later the Cisco CSS 11000 series). I state the product linkage as plausible but not independently verified in this session; what is verified is that Cisco was an operating networking vendor actively shipping routing/switching products that read on this subject matter, and that it cited this patent in later Cisco-family filings.
• Current status: operating. Cisco Systems, Inc. (NASDAQ: CSCO) is a going concern; no bankruptcy, dissolution, or portfolio wind-down affecting this patent was found.
• Note on the entity name: "Cisco Technology, Inc." reads like a holding LLC, but it is not an NPE shell — it is the standard Cisco patent-holding subsidiary, tied to a large operating parent with a physical campus address. Naming alone is not a finding.

Assignment timeline

Caveat, stated plainly: the USPTO Assignment Center / legacy-assignment records were not retrievable via the tools available in this session. I therefore report only the assignment event that is documented in the patent's own legal-events record on Google Patents, and I explicitly flag that the reel/frame number and correspondent of record were not obtained and are not fabricated below. Only one assignment event appears: if a post-issuance transfer existed, it is not reflected in the legal-events record I could reach, and the patent's status is "Expired – Lifetime" with an anticipated expiration of 2019-07-02, meaning ownership is moot for assertion purposes today.

• 1999-07-02 (filing/execution date) / recorded 1999-10-04 — Reel not surfaced
  • Conveyance: Assignment of interest (see document for details)
  • Assignor: Mark Albert; Richard A. Howes; James A. Jordan; Edward A. Kersey; William M. LeBlanc; Louis F. Menditto; Chris O'Rourke; Pranav Kumar Tiwari; Tzu-Ming Tsang (all nine inventors, jointly)
  • Assignee: Cisco Technology, Inc., San Jose, CA
  • Correspondent: not surfaced — could not be retrieved from the sources reached. No recurrence analysis is possible.
  • Context: ordinary inventor-to-employer assignment, recorded ~3 months after filing. Not a fire-sale, not a reorg, not a transfer to an asserter.

No further recorded assignments appear thereafter. Google Patents legal events show only: application filed (1999-07-02), priority (1999-07-02), assignment (1999-10-04), grant (2003-10-14), anticipated expiration (2019-07-02). There is no chain of LLC-to-LLC conveyances, no security agreement, no merger, and no change of name.

Timeline diagram

timeline
    title Ownership of US 6633560
    1999 : Application filed 2 July
         : Inventors assign to Cisco Technology
    2003 : Patent issued 14 October
    2019 : Patent term expires

NPE / troll-pattern signals

1. Shell-entity transfer — Not present. No assignment out of Cisco Technology, Inc. is recorded. The assignee "Cisco Technology, Inc." carries a "Technology" suffix but is a wholly owned subsidiary of an operating parent with a physical San Jose campus, not a registered-agent service address or a single-member Delaware/Texas LLC. No evidence of a licensing-only vehicle in this chain.

2. Known asserter in the chain — Not present. No assignee or prior assignee matches Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, or any Spangenberg entity. The only recorded assignee is Cisco Technology, Inc.

3. Repeat correspondent across the chain — Unclear / not assessable. Only one assignment link exists and the correspondent of record was not retrieved. With a single link, the recurrence test cannot fire even in principle. No correspondent name is asserted here.

4. Cascading transfers (<24 months, chained LLCs) — Not present. No consecutive assignments at all after the initial 1999 employment assignment.

5. Pre-litigation transfer (within 6 months of first suit) — Not present. No infringement suit naming US 6,633,560 was surfaced in searches. The patent additionally expired 2019-07-02 and post-expiry assertion is not possible. The only 1999 transfer predates issuance itself by four years.

6. Bankruptcy fire-sale — Not present. Cisco has not filed Chapter 7/11, and no sale of this patent in any proceeding (Kodak/Nortel/Polaroid-style) was found.

7. Privateering (operating co → NPE asserts on its behalf) — Not present. No NPE was ever inserted between Cisco and the asserted party; there is nothing to assert through.

8. Defensive aggregator (anti-NPE) — Not present. The chain does not terminate at RPX, AST, LOT, Unified Patents, or OIN. The neutralization here came from term expiry (2019-07-02), not from defensive aggregation.

Verdict

Insufficient data — strictly applied, because the record contains only the original assignment (inventors → Cisco Technology, Inc., recorded 1999-10-04) and the reel/frame and correspondent of record could not be retrieved from the USPTO Assignment Center in this session.

Substantively, however, the evidence points the other way from an NPE chain: every one of the eight troll-pattern signals is absent, the sole recorded conveyance is a same-day employment assignment to an operating company's IP-holding subsidiary, and the patent expired on 2019-07-02 while still held by Cisco. If you want a positive characterization, this is a clean single-link operating-company chain; the "insufficient data" label reflects retrieval limits (missing reel/frame + correspondent), not ambiguity about whether an NPE is involved.

Verify directly at: https://assignmentcenter.uspto.gov/ (search patent number 6633560) and the mirror https://assignment.uspto.gov/patent/index.html — pull reel/frame and correspondent for the 1999-10-04 recording to close the one evidentiary gap, and confirm that no later conveyance exists.

I'll research the prior art references cited in US 6,633,560. Let me run targeted searches.

Let me try to retrieve the explicit "References Cited" list from the patent's Google Patents page.

The web index isn't surfacing the citation list directly. Let me try to reach the patent's front page and the USPTO record.

Prior-Art Analysis — US Patent No. 6,633,560

⚠️ Status of this deliverable (read first)

I was not able to retrieve the verified "References Cited" list for US 6,633,560 through the tools available to me. My only tool is general web search, which returned the patent's description text, its classification data, and third-party citation tables (patents that cite '560), but not the front-page list of references cited by the '560 examiner/applicant. The search session also terminated on a step limit before I could iterate further.

I will not fabricate a citation list. Below I clearly separate (a) what I verified, (b) what could not be verified, and (c) candidate prior art for verification, explicitly labeled as my domain knowledge, not confirmed as cited on the '560 face.

Also flagging two inconsistencies:

• Date conflict: This task header says "Current Date: April 26, 2026," while the operating context says *today is 2026-09-30. I proceed on the 2026-09-30 basis and note the discrepancy.
• Number-literal trap observed: One search hit listed US6633560 against "Machine for handling eggs" (a 1960 application). That is an application/serial identifier collision, not the Cisco patent. This is exactly the kind of look-alike the literal-interpretation rule warns against, so I excluded it.

---

1. Verified bibliographic record (US 6,633,560 B1)

Critical prior-art date: Because the application was filed 1999-07-02 and claims no earlier priority, every § 102 reference must predate 1999-07-02 (with § 102(e) reaching earlier-filed US publications/applications). References published after that date (e.g., the family members listed below) cannot be prior art to '560 by definition.

---

2. What I can verify from the patent text itself: related applications (NOT prior art)

The specification's "Cross Reference to Related Applications" lists 13 co-filed Cisco applications (all filed 1999-07-02), which are the true relationship data I can ground:

These matured into siblings such as US 6,549,516; 6,606,315; 6,650,641; 6,687,222; 6,735,169; 6,742,045; 6,836,462.

Anticipation caveat: Same-family/same-inventor applications are not § 102 prior art against each other, and under § 103 they are commonly disqualified as the applicant's own work. A useful confirmatory signal I did observe: the Google Patents family table for JP 4201550 B2 lists US 6,633,560 among Cisco sibling citations — i.e., the ecosystem consistently treats '560 as a citing family member, not a cited-to parent.

---

3. Candidate prior art for § 102 analysis — UNVERIFIED, FOR VERIFICATION ONLY

I could not confirm which of the following actually appear in the '560 "References Cited" list. Treat every item below as a lead to check, not as an established citation. I have flagged my confidence in each.

Well-established pre-1999 references in the four relevant sub-fields:

A. Server-cluster / single-image clustering (relevant to "virtual IP address," "cluster of hosts")

• US 5,371,852 A — Attanasio et al. (IBM), "Method and apparatus for making a cluster of computers appear as a single host on a network." Title/content confirmed in my search results (Google Patents page returned). Issue date mid-1990s. Confidence in existence: high; confidence it is cited on '560: unknown.
• US 5,774,660 A — Brendel et al. (Resonate), "System for distributing load over multiple servers at an internet site." Filed 1996, issued 1998. Confidence in existence: high; citation status: unknown.

B. Distributed / dispatcher-based load balancing (relevant to claim 1's "first/second service manager," "criteria")

• US 6,006,264 A — "Method and system for directing a flow between a client and a server." Filed 1997. Because it predates 1999-07-02 by filing date, it is a § 102(e) candidate even though it published later. Confidence in existence: medium-high; details unverified.

C. Flow-cache / connection-affinity redirection (relevant to "affinity key," "fixed/wildcard affinity")

• US 5,905,899 A — "Method and apparatus for balancing loads among network servers." Confidence: medium.
• US 6,023,563 A — load-balancing in a network. Confidence: medium.
• US 6,112,239 A — "World-wide-web server with delayed resource-binding." Confidence: medium.

D. NAT / forwarding-agent fast-path (relevant to NAT action segments, dispatch/direct flags)

• US 5,793,763 A — "Security system for network address translation systems." Confidence: medium.

Explicit honesty statement: I do not know with high confidence the actual contents of the '560 "References Cited" section, and I could not confirm any of the above as cited. Any § 102 mapping built on this list would be speculative and must not be relied upon.

---

4. § 102 anticipation framework — which claims to target once references are verified

Because the full claim set was not present in the supplied text (the extract ends at the Background), I can only map the claim themes — drawn from the patent's own summary of its claims and its 46 "claim" keyword hits:

Anticipation standard: For § 102, the reference must disclose every element in the same arrangement (no missing element, no re-arrangement). The distinctive hurdle for '560 is the multi-manager partitioning of a client population across a shared set of forwarding agents, driven by manager-issued interest filters, with the client uninvolved. Classic single-dispatcher load balancers (category B above) generally teach one dispatcher, so they more naturally threaten only § 103 (obviousness) than § 102 — but that is a conclusion for a verified claim chart, not this memo.

---

5. Recommended verification steps (to convert this into a defensible clearance)

1. Front-page references — open the granted PDF: https://patentimages.storage.googleapis.com/.../US6633560.pdf (Google Patents → "Download PDF") and read the "References Cited" block directly.
2. USPTO side — PatentCenter / Patent Public Search (ppubs.uspto.gov) → application 09/347,126 → "References Cited by Examiner" and "References Cited by Applicant."
3. File wrapper — the IFW/Patent Center "References Cited" tab to capture examiner-cited art and any IDS.
4. Reexam/IPR check — confirm no third-party art was later added (the record shows none, but verify via PTAB and the "Legal Events" tab).

If you can supply the actual "References Cited" list (or the granted-PDF page image), I will produce the requested reference-by-reference table — full citation, publication/filing date, brief description, and the specific claim(s) each reference potentially anticipates under 35 U.S.C. § 102 — mapped to the verified claim language. Until then, per the no-fabrication rule, I am reporting a gap, not a result.

I'll research prior art relevant to the claims of US 6,633,560 before performing the § 103 analysis.

Let me gather additional prior-art references bearing on the claim elements (flow director, distributed/parallel firewalls, NAT, tag switching, multicast-based interest registration).

Let me gather a few more references on the remaining claim elements (multicast-based registration, NAT, tag switching, and router-based server selection).

Obviousness Analysis — U.S. Patent No. 6,633,560 (35 U.S.C. § 103)

---

A. Preliminary matters, provenance, and caveats

A.1 There is no "Prior Art section" on the page that was supplied to me.
The task directs me to "[u]se the results from the Prior Art section of this page." I must flag explicitly that the fetched Google Patents record for US 6,633,560 (https://patents.google.com/patent/US6633560/en) that was provided contains no References Cited / Prior Art listing. The fetch terminates in the middle of the Background section ("…for the purpose of providing certa"). What is present is a "Prior art keywords" set — packets, affinity, service manager, service, forwarding agent — and the CPC classifications, which I treat below as the Examiner's field-of-search signal (§ D.6).

Consequently, this analysis draws on (i) the patent's own applicant-admitted prior art in its Background, (ii) the front-page "Related Application" cross-references, (iii) the CPC classification set, and (iv) independently researched art in the same art units and date window. Every reference below is dated and its statutory basis is identified. Where I could not verify a reference's content in this session, I say so.

A.2 Claim-text provenance discrepancy (flagged, not silently corrected).
I found two different reproductions of claim 1 of this patent in the sources retrieved:

These are not the same claim. This could reflect an amendment during prosecution, a certificate of correction, or third-party data error. The third-party text also contains an apparent typo ("affinity kev"), which I preserve literally. I could not verify the issued claim set from the authoritative source in this session; accordingly, the element-by-element analysis in § C is written to cover the union of the claim features reproduced in these sources, and I note where a limitation appears in only one version. A definitive § 103 opinion requires the claim set from the USPTO full-text/PatentCenter record or the printed patent.

A.3 Governing law and effective filing date.

• Effective filing date: 1999-07-02 (application 09/347,126; priority date 1999-07-02 per the record).
• Because the application was filed before 2013-03-16, the pre-AIA 35 U.S.C. § 103(a) governs, and pre-AIA §§ 102(a)/(b)/(e) define the available art.
• KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007) supplies the controlling obviousness framework (predictable results, known techniques for their known purposes, design incentives and market pressure, and the "obvious to try" doctrine).
• Status: the patent is recorded as Expired – Lifetime, anticipated expiration 2019-07-02.

A.4 Cross-reference to a prior section — no contradiction.
The prior litigation section concluded no litigation or PTAB proceeding was found naming US 6,633,560. Nothing in the prior-art research contradicts that, and it is relevant here only in one narrow way: there is no adjudicated claim construction, no IPR record, and no commercial-success/secondary-considerations record to draw on. That materially raises the uncertainty band on this § 103 opinion, and I say so in § L.

---

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

Based on the field as reflected in the patent's Background and the CPC classifications, a POSITA at July 1999 would have:

• a bachelor's degree in EE/CS (or equivalent) and 2–4 years designing or administering IP internetworks;
• working knowledge of TCP/IP v4, the 5-tuple flow abstraction, ICMP, and packet-forwarding/route-lookup pipelines;
• working knowledge of router packet classification (access control lists, route maps, extended/established filters — the exact "source IP / destination IP / source port / destination port / protocol" tuple set recited in the patent's affinity key) and of route redistribution and router advertisement;
• familiarity with NAPT/NAT, IP-in-IP encapsulation (RFC 2003), tag switching/MPLS, and IP multicast / group membership (IGMP, RFC 1112);
• familiarity with the server-farm load-balancing appliance product class (LocalDirector, ServerIron, BIG-IP, ArrowPoint, IBM Network Dispatcher, Resonate, HydraWEB) and with DNS round-robin.

That POSITA is the reference point for everything below.

---

C. Claim element breakdown

Using the claim material reproduced in the sources in § A.2, and the specification's own definitions (fixed affinity = per-flow 5-tuple instruction; wildcard affinity = a registered filter over sets of source/destination IP addresses and masks plus ports/protocol; encapsulation of intercepted packets to the service manager; TTL-based refresh/deletion of registered instructions):

The asserted point of novelty, per the specification, is architectural: "the service managers are able to provide network services without physically being inserted at the various points in the network where those services must be provided," and "This contradicts the conventional wisdom regarding the restriction that all traffic inbound for a server cluster must pass through a single load-balancing engine." That sentence is the applicant's own statement of the alleged advance — and, as shown in § J, it is also the weakest link in the non-obviousness case.

---

D. Prior art available as of 1999-07-02

D.1 Choquier et al., U.S. 5,774,668 — § 102(b) art

"System for on-line service in which gateway computer uses service map which includes loading condition of servers broadcasted by application servers for load balancing." Filed 1995-06-07; issued 1998-06-30.
Source: https://patents.google.com/patent/US5774668 ; PDF at https://patentimages.storage.googleapis.com/e3/b1/67/b4987b1f85b941/US5774668.pdf.

Teaches, expressly:

• Multiple gateway microcomputers acting as intermediaries between client microcomputers and groups of replicated application servers ("service groups").
• A service map containing per-server service names, current processing load, and CPU INDEX, "updated on the order of every 30 seconds."
• Load balancing by the gateway: "the Gateway microcomputer determines the current load of each application server in the service group, and applies a load balancing method to select an application server that is relatively lightly loaded."
• Sessions bound per-flow: "Users of a service are assigned to individual application servers on a per-service session basis." This is exactly the "which new flows am I interested in / where does this flow go" abstraction.
• Hot redirection — transferring a live user session from one replicated server to another without terminating it.
• Server groups as a routing target: "routing update messages to servers of particular server groups… based on service maps that map servers to server groups associated with message categories."

Relevance: C3 (division of a service across multiple controllers), C5 (selection among servers), and the general control-plane / data-plane split (the gateway holds the map; the servers merely run).

D.2 Colby et al., U.S. 6,006,264 — § 102(e) art (US application filed 1998-03-30; provisional 60/054,687 filed 1997-08-01)

"Method and system for directing a flow between a client and a server," ArrowPoint Communications (later Cisco). Issued 1999-12-21 — after the '560 filing date, so it is not § 102(a)/(b) art; it is available as § 102(e) art at its 1998-03-30 filing date (and arguably 1997-08-01 through the provisional).
Sources: https://patents.google.com/patent/US6006264A/en; http://www.everypatent.com/comp/pat6006264.html.

Teaches, expressly:

• A content-aware flow switch that intercepts a client request (detects flows "based on the arrival of TCP SYNs and/or HTTP GETs"), and transparently directs the content request to a best-fit server selected on load, congestion, and proximity. → C1, C3(interception), C5.
• An explicit control-plane / data-plane (fastpath) split with programmed forwarding state: "Packets that have not previously been mapped to a physical port are directed to the control plane. The control plane determines the physical port… The control plane is also responsible for updating the forwarding table so that future packets to the same destination may be forwarded directly by the data plane." → C4 (a per-flow instruction written into the forwarder by an off-path decision maker).
• Per-flow network address translation: "the flow switch 110 functions as a network address translation device… the IP, TCP, and possible content headers on packets moving bidirectionally between the client and server are modified as necessary." → C5 (directing to a selected server).
• Explicit flow classification by the 5-tuple: the flow switch "switches packets based on a combination of source and destination IP addresses, transport layer protocol, and transport layer source and destination port numbers." This is verbatim the affinity-key element set of C4.

Relevance: Colby is the single most damaging reference on C1, C4, and C5.

D.3 Brendel et al., U.S. 5,774,660 — § 102(b) art

"World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network," IBM; issued 1998-06-30 (cited as prior art on the face of US 7,487,250 at https://patentimages.storage.googleapis.com/8d/a5/2b/700544098d4672/US7487250.pdf). Teaches a virtual IP address / cluster address fronting a set of real servers, with delayed binding of a connection to a specific server until the request is parsed — i.e., the intercept-first, decide-later, then pin-the-flow model of the '560 specification's Figs. 3A–3C. Relevance: C2, C3, C5.

D.4 RFC 1631, Egevang & Francis, "The IP Network Address Translator (NAT)," May 1994 — § 102(b) art

https://www.rfc-editor.org/rfc/rfc1631 (and mirrors). Expressly teaches a router function that (a) rewrites source/destination IP addresses and, where required, ports; (b) adjusts IP/TCP checksums; (c) performs TCP sequence/ACK number adjustment with a delta table; and (d) uses IP encapsulation/tunneling between boxes ("encapsulate the packet in an IP header with destination address set to the global address of NAT box y… y decapsulates"). Relevance: C5 (redirect to a selected server by address translation) and C6 (encapsulation). Note that the patent's own NAT action segment (Fig. 10F) and sequence-number-adjust segment (Fig. 10G) are a direct restatement of RFC 1631 § 3.3.

D.5 IP multicast / group membership — RFC 1112 (Deering, Aug 1989) and IETF multicast practice — § 102(b) art

Relevance: the '560 specification's mechanism for registering interest with many forwarders at once is "registering to a common multicast group so that neither service managers nor forwarding agents need to have any preknowledge of the existence of each other" and multicasting wildcard affinities to that group. Multicast group-based, no-prior-knowledge registration and distribution of a filter/policy set to a set of network devices was standard practice by 1999 (multicast routing-protocol adjacencies, IGMP, MSDP/PIM-SM rendezvous models, and the multicast "announce/discover" idiom). This is the closest art to the "wildcard affinity multicast to a group of forwarding agents" feature.

D.6 Router packet classification (ACLs / route maps / flow caches) — well-known art, admitted on the face of the patent

The affinity key of C4 is the standard extended-IP ACL key (src/dst IP, src/dst port, protocol) that had been a Cisco IOS router primitive since the early 1990s, and the "advertise" action segment of Fig. 10H is ordinary route redistribution/route advertisement. This is confirmed by the patent's own CPC classifications, which place it squarely in firewall/service-delivery art:

• H04L63/02 — network security architectures; H04L63/0218 — distributed firewalls;
• H04L67/1001 — replicated servers; H04L67/563 — data redirection of data network streams;
• H04L41/508 / H04L41/5096 — network service management.

That the USPTO itself classifies this patent under "distributed firewalls" and "accessing one among a plurality of replicated servers" is itself evidence that the claimed subject matter was a recognized combination of two known fields.

D.7 Applicant-admitted prior art in the '560 Background — admissions usable under § 103

The specification concedes: NAT, statistics gathering, load balancing, proxying, intrusion detection and security services were all known appliance functions; clustering and cluster load balancing were known; and — crucially — "[p]artitioning of the work is done by the client population. For example, if multiple parallel firewalls are needed to protect a site, then clients must be individually configured to use a firewall or must somehow be assigned to a certain firewall when needed." The applicant therefore admitted that partitioning a service by client population was an existing, known technique, and identified the only remaining problem as doing it without client reconfiguration.

D.8 Related same-day Cisco applications — NOT available as § 103 art

The Cross-Reference section lists twelve co-pending applications (Ser. Nos. 09/346,634; 09/347,124; 09/347,111; 09/347,428; 09/347,122; 09/347,108; 09/347,034; 09/347,048; 09/347,125; 09/347,123; 09/347,109; 09/347,036), all filed on 1999-07-02, the same day as the '560 application. Because pre-AIA § 102(e) requires the reference application to have been filed "before the invention by the applicant," a same-day, commonly owned filing does not on its face qualify; and the content is not public art under 102(a)/(b) as of that date. These should not be used in a § 103 combination against '560. I flag this because these sibling patents appear repeatedly in the "similar documents" / citation graphs for '560 and would be an error to treat as prior art.

D.9 A reference that must NOT be used — Bellovin, "Distributed Firewalls"

Steven M. Bellovin, Distributed Firewalls, ;login:, pp. 37–39/39–47, November 1999, and the AT&T Labs talk dated August 23, 1999 (https://www1.cs.columbia.edu/~smb/talks/distfw.pdf, http://www.cs.columbia.edu/~smb/papers/distfw.html, https://atc.usenix.org/legacy/publications/login/1999-11/features/firewalls.html).

This is the academic paper that most neatly states the '560 architecture's premise — "Control remains centralized"; "Does not rely on topology"; "No single point of failure"; "a compiler translates the policy into filter rules; the management tool distributes the policy to all endpoints; endpoints accept or reject packets." But it post-dates the 1999-07-02 filing date and is therefore NOT prior art against '560. I include it here only to (a) demonstrate that the idea became the published state of the art in the same year, which bears on the level of ordinary skill, not on § 102; and (b) caution against the common error of citing it. If a pre-July-1999 variant is needed, the earlier work cited in the NATO/RTO survey (Chitturi, M.S. thesis, University of Utah, June 1998, on "implementing mandatory network security in a policy-flexible system," and the Fluke-kernel work) is a § 102(b) candidate, but I did not verify its content in this session and cannot opine on what it discloses.

---

E. Ground 1 — Choquier '668 in view of RFC 1631 (NAT) and the admitted router-classification art; further in view of multicast registration (RFC 1112)

Proposed rejection: Claim 1 (and claims 2–3) obvious over Choquier in view of RFC 1631, further in view of router ACL/route-map classification as admitted by the '560 specification, optionally further in view of RFC 1112 / IP-multicast group registration.

Rationale / motivation. Choquier supplies the division of a network service across multiple intermediary computers and the load-balanced selection of a real server for a session; RFC 1631 supplies the machine-level mechanism (in-router, per-flow address/port/sequence rewriting and encapsulation) by which a routing device — rather than an inserted appliance — can redirect an intercepted flow to a chosen real server. A POSITA would combine them because the combination is the substitution of one known forwarding mechanism for another to achieve the same predictable result (deliver a flow to the server the balancer chose), and because RFC 1631 was the standard, off-the-shelf tool for exactly that job.

---

F. Ground 2 — Colby '264 in view of Choquier '668; further in view of RFC 1631

This is the strongest ground, because Colby alone reaches most of the claim and Choquier supplies the multi-controller partition.

F.1 What Colby alone discloses.

• Interception of new flows at network infrastructure: "the flow switch detects client-server flows based on the arrival of TCP SYNs and/or HTTP GETs from the client"; "the content request is intercepted by the content-aware flow switch." → C1, C2 (first criteria).
• A per-flow instruction, keyed on the 5-tuple, written into the forwarder by an off-path decision maker: "The control plane… is responsible for updating the forwarding table so that future packets to the same destination may be forwarded directly by the data plane"; the switching key is "source and destination IP addresses, transport layer protocol, and transport layer source and destination port numbers." → C4 (the affinity key 5-tuple and the "receive instructions from a service manager at the forwarding agent" element).
• Direction to a selected server, by NAT: "the flow switch 110 functions as a network address translation device… the IP, TCP, and possible content headers… are modified as necessary." → C5.

F.2 What Choquier supplies that Colby lacks. Colby's flow switch is a single element; it does not itself teach two service managers partitioning a client population among themselves so that a forwarding agent routes matching flows to whichever manager registered the criterion. Choquier does: multiple Gateways; each user's session bound to a Gateway; service groups; load-condition-driven selection. Choquier's teaching that "server groups can be assigned to handle a specific topic or set of topics" (as reproduced in the PTAB petition at https://ptacts.uspto.gov/ptacts/public-informations/petitions/1557874/…) is a partitioning-by-category teaching directly analogous to partitioning by client subnet.

F.3 What RFC 1631 supplies. The precise in-router mechanics of the "action" the service manager pushes down (address/port substitution, checksum adjustment, TCP sequence/ACK delta tables, encapsulation) — i.e., the content of the fixed affinity.

F.4 Motivation to combine (KSR). Both references address the same problem — scaling a network service beyond the capacity of a single inserted box — and both solve it by relocating the decision logic out of the packet path. Colby's stated advantage — "content-aware flow switches can be interconnected and overlaid on top of an IP network to provide content-aware flow switching regardless of the underlying technology used by the IP network. In this way, the invention provides content-aware flow switching without requiring modifications to the core of existing IP networks" — is the identical design incentive that motivates adding Choquier's multiple-controller partition. Combining them yields no more than "the predictable use of prior art elements according to their established functions." KSR, 550 U.S. at 417.

---

G. Ground 3 — Brendel '660 in view of Choquier '668 and RFC 1631

Brendel supplies: virtual IP/cluster address; delayed binding (intercept the connection, decide later, then pin the flow); distributed multi-node server organization. Choquier supplies the multi-intermediary partition and the load-condition map. RFC 1631 supplies the redirect mechanism. This ground is cumulative and somewhat weaker than Grounds 1–2 (Brendel is a server-side, single-entry architecture), but it independently corroborates that "intercept a new flow at infrastructure, consult off-path state, then program a per-flow forward instruction" was known.

---

H. Ground 4 — The pre-1999 distributed-policy-enforcement art in view of Choquier and admitted router classification

The '560 specification's own admission that "[i]f multiple parallel firewalls are needed to protect a site, then clients must be individually configured to use a firewall or must somehow be assigned to a certain firewall when needed" concedes that (i) parallel, load-sharing network service devices were known, and (ii) the only thing deemed missing was eliminating client-side control. The patent's stated contribution ("[r]emoving control from the clients would create a more stable, controllable, and predictable network environment") is therefore a design-tradeoff optimization of an admitted known architecture, not a new mechanism.

Pair that admission with (a) Choquier's map-driven assignment of clients to intermediaries, and (b) the admitted, ubiquitous router ACL/route-map classification, and the recited "first criteria / second criteria" partition is reached without any reference to the post-dated Bellovin paper. Note my caution: because I could not verify the substantive content of any specific pre-July-1999 distributed-policy paper in this session, I would not plead Ground 4 as a standalone rejection; it is best used as corroboration of the admitted art under § D.7.

---

I. Why a POSITA would have been motivated to combine — consolidated

1. Same problem, same field. Every reference addresses the single-port-of-scale problem of the appliance-in-the-path. The '560 Background states the problem verbatim ("This limits the scalability of the service to the capacity of a single box that is inserted in the data stream").
2. Predictable result / known technique. Distributing a partition of a workload across N parallel instances, and programming a forwarding element with a match-and-act entry, are each ancient, well-understood techniques applied to their customary purpose. KSR, 550 U.S. at 417.
3. Control-plane/data-plane separation was already the architectural idiom. Colby states it expressly; RFC 1631 embodies it in a router (translate, don't terminate); Choquier embodies it in a gateway (hold the map, don't run the service).
4. Market pressure. Explosive late-1990s web/Internet growth, plus the well-documented fact that network access "must likewise be scalable and highly available" (the patent's own words), supplied a strong, articulated incentive to remove the single box and let existing routers do the interception.
5. Explicit "obvious to try" posture. Once Colby's flow switch, Choquier's multi-gateway partition, and RFC 1631's in-router rewriting are on the table, there is a finite, small, and predictable set of ways to combine them (put the decision function off-box; register filters; push per-flow instructions) with a reasonable expectation of success.
6. The patent's own admission closes the gap. The applicant characterized the multi-appliance partition as already practiced (by client configuration). Changing how the assignment is expressed — from a client-side profile to a filter registered with the network — is the kind of substitution of one known technique for another that KSR makes obvious.

---

J. Where the obviousness case is weakest (and what the patent owner would argue)

I want to be candid rather than one-sided.

J.1 The genuinely distinguishing feature. None of Choquier, Colby, Brendel, or RFC 1631, as I have verified them, expressly teaches a routing device that simultaneously:
(a) holds multiple, independently registered filter specifications from multiple controllers;
(b) forwards matching new flows to whichever controller registered that criterion — i.e., the forwarder performs the manager-selection;
(c) while still continuing to forward the flow under a later, per-flow instruction; and
(d) doing so without any client-side configuration and without the flow having to traverse a single choke point.

Element (b) in particular — manager selection pushed into the forwarder rather than residing in a dispatcher — is the most defensible distinction. The strongest counter-references I could verify are Colby's control-plane-populates-fastpath teaching and Choquier's service map; neither is a two-controller registration model. The closest true analogue I am aware of is multicast-based router group membership + policy distribution (Ground 1's RFC 1112 limb), and I have not verified a reference that combines that with per-flow forwarding. A rigorous challenge here would need a concrete, dated reference — e.g., a 1997–1999 IETF/industry document on distributed policy or router-assisted server load balancing. I did not find one in this session and cannot supply one.

J.2 The applicant's "teaching away / conventional wisdom" argument. The specification asserts: "This contradicts the conventional wisdom regarding the restriction that all traffic inbound for a server cluster must pass through a single load-balancing engine." Patent owners use assertions like this to argue a prejudice against the claimed arrangement. This argument is weak against Grounds 1–2, because: (i) the alleged prejudice is asserted in the applicant's own conclusory words with no documentary support; (ii) Choquier itself already distributed the intermediary function across multiple Gateway machines fronting a shared farm, which undercuts the premise that the art was uniformly single-engine; and (iii) a "conventional wisdom" that is refuted by the applicant's own admitted prior art cannot carry the day.

J.3 Where the claim draft may actually save the patent — the "criteria" breadth. Note a subtlety. If "criteria" in C2/C3 is construed broadly (any match condition), Grounds 1–2 are strong. If it is construed (as the specification's wildcard affinity suggests) to require masked-range matching over sets of source and destination IP addresses plus ports and protocol, then the art's packet-classification teachings still cover it (ACLs and route maps with wildcard masks were router primitives, and Colby expressly keys on the 5-tuple), so my conclusion does not change — but the analysis becomes a subnet-mask-arithmetic argument (wildcard masks = ACL wildcard masks) rather than a flow-cache argument. Either way, obviousness holds.

J.4 Secondary considerations. Per § A.4, I have no evidence of commercial success, licensing, copying, industry praise, or long-felt need tied to this patent. The patent expired in 2019 without (so far as the prior section could determine) any assertion campaign. There is therefore no secondary-considerations evidence to rebut the prima facie case — but conversely, the absence of litigation means there is no adjudicated validation of the analysis either.

---

K. Summary of the § 103 conclusions, with confidence levels

Bottom line. On the art I could verify, claim 1 of US 6,633,560 — and dependent claims 2 and 3 — would have been prima facie obvious under pre-AIA § 103(a) over Colby '264 in view of Choquier '668, further in view of RFC 1631 (Ground 2), and over Choquier '668 in view of RFC 1631 and the admitted router-classification art (Ground 1). The strongest, most defensible distinction the patent owner could press is the forwarder-resident, multi-controller registration/selection mechanism of C3 — and I was not able to locate a verified pre-1999 reference that squarely discloses it, so that limitation remains the pivot on which the outcome of a real challenge would turn.

---

L. What I could not establish — and what to do next

I want to be explicit that this is a preliminary, opinion-grade analysis, not a freedom-to-operate or validity clearance, and to state my limits plainly:

1. I did not have the patent's actual "References Cited" section. The supplied page contains none; the full-text and the file-wrapper (IDS/PTO-892) listings must be pulled from PatentCenter to know what the Examiner actually considered. Had the IDS listed Colby or Choquier, that would strengthen the § 103 case considerably (Examiner-considered art).
2. The issued claim set is not verified (§ A.2) — two sources give materially different claim 1 text. Do not rely on the claim-text reproduction on third-party sites. Pull the claims from the printed patent / PatentCenter.
3. I verified content only for: Choquier US 5,774,668; Colby US 6,006,264; RFC 1631; Bellovin (and only its date/conclusion). For Brendel US 5,774,660, RFC 2105 (tag switching), RFC 2003 (IP-in-IP), RFC 1112, and the Chitturi 1998 thesis, I relied on secondary citation and general knowledge — their substantive content should be confirmed before being pleaded.
4. I did not search for pre-1999 router-vendor or IETF documentation on distributed policy enforcement or router-assisted server load balancing, which is precisely the gap identified in § J.1. That is the highest-value next search.
5. Bellovin must not be cited as prior art (§ D.9). Check any automated prior-art tool's output for this error, and for the same-day Cisco sibling applications (§ D.8), before relying on it.

If you can supply (a) the issued claim set and (b) the References Cited / IDS listing from the file wrapper, I can convert § C into a strict limitation-by-limitation chart and give you a defensible per-claim conclusion rather than the consolidated one above.