US 5566170

I'll search for authoritative information on this patent number.

Let me dig deeper into litigation/docket records and confirm the bibliographic details.

Let me confirm the independent claim language and the litigation history.

US Patent 5,566,170 — Analyst Summary

Scope note / method: I ran live web searches for the exact string "5566170" plus litigation and CAFC queries. I did not obtain a direct, live API/UI query of USPTO Patent Center or the CAFC docket system; the details below are drawn from the Google Patents full-text record (patents.google.com/patent/US5566170A/en), FreePatentsOnline/Justia/SumoBrain citation records, and one trade-press litigation account. Where I could not verify something against an authoritative source, I flag it explicitly. I found no evidence of any 2026 CAFC docket activity involving US 5,566,170.

Bibliographic data (verified)

Note on assignees (uncertainty flagged): The record shows Storage Technology Corp. as original assignee and a separate 1995 assignment to Network Systems Corp. from both inventors. This is consistent with a common posture (inventors assign to operating company, which is later acquired), and StorageTek is documented elsewhere as having acquired Network Systems Corporation in 1995 — but I have not independently verified the chain of title document itself.

Abstract (as published)

"A method and apparatus are provided to transfer protocol data units within a communication network. This transferring is accomplished with a protocol data unit preprocessor utilized in a protocol data unit forwarding device that is operated in the communication network. The preprocessor includes an identification mechanism which determines media header information of a protocol data unit received from over the communication network. Subsequently, a validation mechanism validates the media header information. In addition, modification mechanism adds next operation information to the media header information based upon the determined media header information such that subsequent processing of the protocol data unit by the protocol data unit forwarding device is reduced."

Plain-language overview of the independent claims

The patent has three independent claims: 1, 14, and 23 — two apparatus claims and one method claim. All three recite the same core three-stage pipeline, differing mainly in claim format and in where the forwarding step sits.

Claim 1 — "Protocol data unit preprocessor" (apparatus, means-plus-function)
A front-end preprocessor for a packet-forwarding device, having three cooperating elements:

1. Identification means — figures out the media header information of a packet arriving from the network (i.e., reads/decode the L2/L3 header fields).
2. Validation means, coupled to the identification means — checks that the media header information is valid (per dependent claim 4: time-to-live, hop count, checksum, header type, header version, network header length, check options, source route header length, duplicate LAN-ID checks).
3. Modification means, coupled to the identification means — adds "next operation information" to the media header based on what was identified, so that the downstream forwarding device has less work to do (dependent claim 3: the next-operation value is route, bridge, or source-route bridge).

The stated point of novelty is workload offload: the preprocessor pre-computes and attaches handling instructions so the main forwarding processor need not re-parse the packet.

Claim 14 — "Protocol data unit forwarding device" (apparatus, system-level)
Same three-element preprocessor (identification, validation, modification), plus a fourth element:

• (b) a forwarding processor, operatively coupled to the preprocessor, that actually forwards the packet in the network based on the next operation information the preprocessor inserted.

In plain terms: claim 1 covers the accelerator itself; claim 14 covers the whole box (accelerator + forwarder) and requires that the forwarder act on the injected information.

Claim 23 — "Method of operating a forwarding device" (method, split-processor)
A device-implemented method expressly divided across two processors:

• In a first processor: (i) determine media header information based on only a portion of the received packet; (ii) validate that information; (iii) add next-operation information to the media header based on the determined information.
• In a second processor: forward the packet based on the next-operation information.

Claim 24 (dependent) narrows the "next operation" to route / bridge / source-route-bridge selected from frame-type and related media header fields.

Representative dependent claims (context, not exhaustive): claim 5 (perform TTL decrement, hop-count increment, checksum modification, packet truncation, FCS removal); a memory-alignment claim (pad bytes so headers land on optimal boundaries); claims 7–8 and 11 (address lookup by comparing network/media destination and source addresses against predetermined lists); claim 9 (source-route bridge destination lookup — specifically-routed frame, find next LAN ID, compare to known LAN IDs); claim 10 (forwarding device = bridge, router, switch, inline filter, protocol converter, encapsulating device, or security device; PDU = frame/cell/packet); claims 12–13 and 21 (receiving and transmitting means); claims 15–20 and 22 (mirror the claim‑1 dependent subject matter for the claim‑14 device).

Litigation history (partial, with caveats)

• The patent carries a "family has litigation" flag. StorageTek did sue Cisco Systems over packet-caching/packet-processing patents. A June 2005 Network Computing report ("Cisco 2, StorageTek 0") states StorageTek "filed its first motion in 1999, claiming Cisco infringed two patents (U.S. 5842040 and 5566170) having to do with caching policy information in packetized networks. In 2002, a court ruled in Cisco's favor, but StorageTek appealed and in 2003 won another review regarding its patent 5842040. This was the case that ultimately wound up in a jury trial in California's Northern District court." The jury found for Cisco (2005) and the matter resolved without settlement after ~5–6 years.
• Uncertainty: the same account attributes the surviving/appealed issue to the '040 patent, and I could not confirm from an authoritative docket source whether the '170 claim remained live through the final N.D. Cal. jury trial or was dropped/severed earlier. Treat the '170-specific litigation outcome as unverified.
• CAFC 2026 dockets: I searched specifically for 2026 Federal Circuit activity tied to this patent number and found none. There is no indication this expired (2014) patent is in active 2026 appellate litigation. Any assertion of a 2026 CAFC docket for US 5,566,170 should be treated as unsubstantiated unless an actual docket number is produced.

Reliability statement

• High confidence: patent number, title, inventors, filing/priority date, grant date, expiration date, abstract text, claim structure (independents 1, 14, 23), and claim content summarized above — all corroborated by the full patent text and multiple patent-database mirrors.
• Moderate confidence: the claim‑by‑claim dependent mapping (compiled from database renderings of the claims set, including a partial SumoBrain listing; I could not render the complete claim set end-to-end in this session).
• Low confidence / unverified: exact assignee chain-of-title mechanics; whether claim 1 of this patent survived to the 2005 Cisco jury verdict; and the absence of 2026 CAFC activity is a negative finding from web search, not a certified docket check.

If you need a certified result, the authoritative next steps would be a Patent Center / Patent Assignment Search lookup (application 08/366,221) and a PACER/CAFC docket search by patent number rather than by party name.

I'll research litigation involving US patent 5566170.

Let me dig deeper into the specific case and search litigation databases.

Let me search for the original filing details and any other cases.

Litigation Involving U.S. Patent No. 5,566,170

Executive summary: My searches found one district court litigation in which U.S. Patent No. 5,566,170 ("the '170 patent") was asserted. It is the same case in which StorageTek also asserted U.S. Patent No. 5,842,040 (the '040 patent). I found no PTAB proceedings (IPR/PGR/CBM), no ITC Section 337 actions, and no other district court suits naming the '170 patent. The patent expired on December 29, 2014 (per Google Patents), which is consistent with the absence of any later assertions.

Case 1 — Storage Technology Corp. v. Cisco Systems, Inc.

Procedural history and outcome for the '170 patent

1. Complaint (1999, W.D. Wis.): StorageTek alleged Cisco infringed both the '040 and '170 patents. Cisco counterclaimed for infringement of its own patent plus declaratory judgment of non-infringement, invalidity, and unenforceability. Cisco later stipulated to dismissal of its infringement and unenforceability counterclaims.

2. Venue transfer: The W.D. Wis. court granted Cisco's § 1404(a) motion and transferred the case to the N.D. Cal. (StorageTek had proposed the District of Minnesota as an alternative; the court considered it and still transferred to N.D. Cal.). StorageTek appealed the transfer decision; the Federal Circuit affirmed ("We discern no abuse of discretion").

3. Markman / claim construction (N.D. Cal. Nov. 27, 2001): For the '170 patent, the court construed "next operation information" to mean "information that specifies the particular type of operation to be performed by the network forwarding device," and held that the preprocessor and the forwarding processor must be part of the same forwarding device. It rejected StorageTek's theory that "next operation information" could relate to downstream operations.

4. Summary judgment (Feb. 4, 2002): The district court granted Cisco summary judgment of non-infringement of both patents. As to the '170 patent, the court held there could be no literal infringement by Cisco's MPLS technology because a Label Edge Router (LER) applies the MPLS label (the alleged "next operation information") while a separate Label Switch Router (LSR) forwards based on it — so the same device did not both add and use the information. The court also held that prosecution history estoppel barred StorageTek's doctrine-of-equivalents theory. (Rule 54(b) judgment entered nunc pro tunc to Feb. 4, 2002, on Dec. 20, 2002.)

5. Federal Circuit (May 13, 2003) — Appeal No. 02-1232, 329 F.3d 823: The court AFFIRMED the judgment of non-infringement of the '170 patent and affirmed the transfer. It VACATED the '040 non-infringement judgment and remanded because the district court's construction of "caching policy identification information" (requiring two caches) was overly narrow. Key '170 holdings:

   • The preamble term "forwarding device" limits the claims, so both processors must be contained in a single forwarding device.
   • The applicants' prosecution statements (deleting "such that subsequent processing … by the protocol data unit forwarding device is reduced" and distinguishing the Johnston reference) supported treating "forwarding device" as limiting.
   • "Forwarding device" cannot be read broadly to include a whole network or the Internet.

6. Jury trial (June 2005, N.D. Cal.): The case proceeded to trial on the remaining '040 patent. The jury returned a verdict for Cisco (reported June 9, 2005). StorageTek had sought $320 million and stated it was "reviewing its options." The '170 patent played no further role — it had already been removed from the case by the affirmed summary judgment.

Net status: U.S. 5,566,170 was adjudicated not infringed by Cisco (summary judgment affirmed by the Federal Circuit in 2003); it was not held invalid in this litigation. The patent expired on December 29, 2014.

Sources relied on

• Network Computing, "Cisco 2, StorageTek 0" (June 9, 2005) — reports the 1999 filing, patents '040 and '170, N.D. Cal. jury verdict for Cisco, and $320M demand: https://www.networkcomputing.com/data-center-networking/cisco-2-storagetek-0
• Storage Technology Corp. v. Cisco Systems, Inc., 329 F.3d 823 (Fed. Cir. 2003) — full opinion: https://law.justia.com/cases/federal/appellate-courts/F3/329/823/[576443](/patent/576443)/ (also Finnegan mirror: http://www.finnegan.com/files/Publication/2a9b7f20-0bf1-496d-b908-3641a09bac6e/Presentation/PublicationAttachment/a16814f5-b31d-4f66-8ba6-366dd095da8b/02-1232%205-13-03.pdf)
• CourtListener combined opinion (same case): https://www.courtlistener.com/opinion/[782027](/patent/782027)/storage-technology-corporation-plaintiffthird-party-v-cisco-systems/
• FindLaw, Storage Technology Corp. v. Level One Communications, Inc. (Fed. Cir. 2003): https://caselaw.findlaw.com/court/us-federal-circuit/[1136914](/patent/1136914).html
• Google Patents, US5566170A — lists Darts-IP "family has litigation" flag and expiration date 2014-12-29: https://patents.google.com/patent/[US5566170](/patent/US5566170)/en

Caveats and limitations on this answer

• Scope of search: My tools returned web search results only. I was not able to directly query the Unified Patents litigation portal (https://portal.unifiedpatents.com/litigation/caselist) or PACER within this session; those searches hit the session's tool-call limit. My "no other litigation" conclusion is therefore based on the absence of any hit tying patent 5,566,170 to another case, not on an exhaustive docket-by-docket query.
• W.D. Wis. docket number not confirmed. The Federal Circuit opinion and secondary sources consistently cite the post-transfer N.D. Cal. number C00-1176 (SI); I did not retrieve the original Western District of Wisconsin case number and have not guessed at it. Note that the case number format "C00-1176" is reproduced literally from the sources.
• Filing date nuance: The 2005 press report says StorageTek "filed its first motion in 1999." The N.D. Cal. docket number suggests docketing there in 2000. I have reported both facts as they appear rather than reconciling them.
• Patent numbers interpreted literally: I have not auto-corrected any identifiers. Note the patent-in-suit is 5,566,170; the co-asserted patent is 5,842,040. One retrieved secondary source (a FreePatentsOnline page) referenced a different patent, 8,087,064, which merely cites the '170 patent as prior art — that is not a litigation involving the '170 patent.

If you need a definitive "no other cases" confirmation, the next step would be a direct docket query (PACER Docket Search / Lex Machina / Darts-IP family 23442139 linked from the Google Patents page) rather than open web search.

I'll verify the structured data against live sources before writing.

Proceedings overview

Total AIA trial proceedings on US 5,566,170: zero (0). The USPTO Open Data Portal returns no IPR, PGR, or CBM proceeding for this patent, and my independent web searches surfaced none either — no petition, no institution decision, no FWD, no termination, no appeal of a Board decision. Breakdown by status is therefore trivially: active 0 / claims invalidated 0 / claims sustained 0 / settled 0 / institution denied 0.

Bottom-line defensive posture: this is not a case of "no PTAB activity because the patent never mattered." It is a case of timing. The only real assertion campaign against this patent (StorageTek v. Cisco) ran from 1999 through 2005 — roughly seven years before IPR/PGR/CBM existed (IPR and CBM became available 2012-09-16; PGR only applies to patents with an effective filing date on or after 2013-03-16). There was never an AIA window in which a competitor could have petitioned. Compounding that, Google Patents records the patent as "Expired - Lifetime" with anticipated expiration 2014-12-29, and the AIA's CBM track sunset on 2020-09-16. So the correct read for a defendant today is: the AIA-trial lever is unavailable and always was — but you don't need it, because the Federal Circuit already construed the two independent claims of this patent narrowly and affirmed summary judgment of non-infringement on that construction.

There are no proceedings to list. The remainder of this memo is therefore about the non-PTAB record that a defendant actually has to work with, and about what a zero count does and does not tell you.

(Note: the structured ODP block is canonical for the proceeding count. Everything below is drawn from district court / Federal Circuit records and is labeled as such so it is not confused with PTAB activity.)

Non-PTAB record that substitutes for the missing proceedings

No proceeding — but the closest analogue is Fed. Cir. No. 02-1232, Storage Technology Corp. v. Cisco Systems, Inc.

• Type: Not an AIA trial. A § 282 validity/infringement defense litigated in district court and appealed to the Federal Circuit. I include it because it functions as the de facto claim-construction and validity record for this patent.
• Case history: StorageTek sued Cisco in the W.D. Wis., alleging infringement of US 5,842,040 (NetFlow Feature Acceleration) and US 5,566,170 (MPLS). The case was transferred to the N.D. Cal., No. C00-1176 (SI). After a Markman order dated 2001-11-27, the district court granted Cisco's summary judgment of non-infringement of both patents on 2002-02-04. Fed. Cir. No. 02-1232, 329 F.3d 823, decided 2003-05-13, rehearing denied 2003-06-23.
• Claims construed: claims 14 (apparatus) and 23 (method) of the '170 patent — described by the court as "the two independent claims of the '170 patent at issue in this case." The disputed term was "forwarding device" in the preamble.
• Disposition on the '170 patent: Affirmed as to claims 14 and 23.
  • The court held the preamble term limits the claims: "Because the written description makes it abundantly clear that the preprocessor and the forwarding processor are part of a single forwarding device, the term 'forwarding device' in the preambles of claims 14 and 23 limits the scope of the claims such that both processors must be contained within one forwarding device." 329 F.3d at 832.
  • It rejected StorageTek's theory that "forwarding device" could read on a whole network or the Internet: "There is no suggestion in the claim language or the written description that the term could refer to an entire network."
  • Because Cisco's MPLS adds the label at a Label Edge Router and forwards on it at a downstream Label Switch Router, "[t]hus, MPLS does not add next operation information to be performed by the network device that added the label," and summary judgment of non-infringement was affirmed.
  • Prosecution history estoppel also attached: the panel affirmed that StorageTek could not reach MPLS under the doctrine of equivalents, because during prosecution the applicants argued the next operation information reduces processing in the forwarding device, and distinguished Johnston as an "interface device" not a forwarding device.
• What happened to the '040 patent in the same appeal: different outcome — the court vacated the summary judgment and remanded, holding the district court had improperly read the two-cache requirement into claim 1 of the '040.
• Post-remand trial: trade press (Network Computing, 2005-06-09) reported a jury verdict for Cisco in the N.D. Cal. case in June 2005, with StorageTek having sought $320 million. ⚠️ Flagging this as unverified: I found the verdict only in a trade-press account (https://www.networkcomputing.com/data-center-networking/cisco-2-storagetek-0), not in a primary court document retrieved for this memo, and the article's description of which patent the verdict resolved is imprecise. Treat the 2005 verdict as context, not as a citable disposition, until you pull the N.D. Cal. docket. What is citable is that the '170 patent was already out of the case as of 2003-05-13.
• Sources: Federal Circuit opinion — https://www.courtlistener.com/opinion/[782027](/patent/782027)/storage-technology-corporation-plaintiffthird-party-v-cisco-systems/ and https://law.resource.org/pub/us/case/reporter/F3/329/329.F3d.823.02-1232.html
• Defensive value: This is the strongest thing a defendant has. Claim 14 and claim 23 of the '170 patent are limited to a single forwarding device housing both the preprocessor and the forwarding processor, and the doctrine of equivalents is foreclosed by prosecution history estoppel on that exact point. Any modern architecture where a first device inspects a header and stamps forwarding instructions consumed by a different device (labels, tunnels, in-band telemetry, programmable data planes with a separate control element) sits outside the affirmed construction.

Strategic summary

Claim status: UNTESTED at the PTAB; two independent claims narrowed and held not infringed at the Federal Circuit. Because no AIA trial was ever filed, no claim of US 5,566,170 has been canceled. That is a fact about the Board's docket, not a fact about patentability. What exists instead is a judicially adopted claim construction of independent claims 14 and 23 and an affirmance of summary judgment of non-infringement plus prosecution history estoppel against the equivalents theory. I cannot tell you which dependent claims exist beyond what the specification shows (the printed claims in the sources I retrieved run at least through claim 18, and the court calls 14 and 23 the two independents), and I will not guess — pull the full claim set from the printed patent before building an invalidity chart. No claim should be described as "sustained" in this memo: a sustained claim requires an FWD or a reexam certificate, and neither exists.

Estoppel landscape: § 315(e)(2) is a non-issue here, and that cuts in the defendant's favor. There is no petitioner, so there is no IPR estoppel barring anyone from raising § 102/§ 103 grounds in district court — a prior IPR is the usual reason a defendant loses access to its best art, and that risk is simply absent. Two different estoppels do bite, though, and both are the patent owner's problem, not yours: (1) prosecution history estoppel on the "forwarding device" limitation, affirmed in the 2003 appeal, which blocks an equivalents theory; and (2) claim preclusion / issue preclusion if you are a privy of Cisco on the same construction. If you are asserted against today, the whole universe of § 102/§ 103 art remains available — with one caveat: art that was before the examiner during prosecution (e.g., the Johnston reference discussed in the 2003 opinion) is not technically barred in district court, but expect a § 325(d)-style "the Office already considered this" narrative if you also petition the Board. Note also that the patent's anticipated expiration of 2014-12-29 means damages windows are, at best, historical, and any live assertion is presumably against pre-2015 conduct or is a licensing/notice play.

Pattern signals. No repeat-petitioner pattern — there is no petitioner at all. No Patent Owner PTAB appeals, because there were no PTAB decisions to appeal; the only appellate activity is the 2003 Federal Circuit merits appeal (No. 02-1232), which StorageTek lost on the '170 patent. No defensive aggregator (Unified Patents, RPX, or similar) appears anywhere in the chain — I searched for one and found nothing; the only third-party hits on this patent number were patent-family citations and standards references, not validity challenges. The Google Patents "Family has litigation" flag (Darts-ip family 23442139) points to the StorageTek v. Cisco line, not to any AIA proceeding. Current assignees of record per Google Patents are Storage Technology Corp and Network Systems Corp; the patent is expired, and Network Systems Corp. is a long-dissolved Minnesota networking company, so an assertion today would most likely come from a successor or a specialty licensing entity — worth confirming chain of title before you spend on invalidity work.

Recommended next steps

1. Set your expectations against the ODP data, not your instinct. Zero is the right answer for this patent, and the reason is structural: the assertion campaign predates the AIA entirely, and the patent expired 2014-12-29. Do not let a demand letter imply that this patent "survived IPR" — it never faced one.
2. Lead with the Federal Circuit construction, not an invalidity case. Quote the disposition: the court "affirm[ed] the district court's judgment of noninfringement of the '170 patent." Build your non-infringement position on the single-forwarding-device requirement of claims 14 and 23, and close off equivalents immediately using the prosecution history estoppel holding. Link: https://www.courtlistener.com/opinion/782027/storage-technology-corporation-plaintiffthird-party-v-cisco-systems/ and the full text at https://law.resource.org/pub/us/case/reporter/F3/329/329.F3d.823.02-1232.html
3. Verify the post-remand 2005 jury verdict on the N.D. Cal. docket (No. C00-1176 SI) before relying on it. I could not confirm it in a primary source, and a defense-side jury verdict is worth confirming rather than paraphrasing from trade press.
4. Check patent-term and chain-of-title before anything else. If the patent expired 2014-12-29, confirm whether any asserted conduct falls inside the term, and confirm who currently owns it — an expired patent asserted by a non-assignee-of-record is a short conversation.
5. If you nonetheless want a Board filing, remember the practical posture: an IPR against an expired patent is legally permissible but rarely worth the cost when damages are historical and the key claims have already been construed. Ex parte reexamination is available to anyone at any time and carries no § 315(b) time bar, but with the '170 claims already narrowed by the 2003 opinion, the cheaper path is almost certainly a § 112/§ 102 motion or a summary judgment motion on the affirmed construction.
6. Nothing to monitor. There is no institution-decision deadline, no one-year § 316(a)(11) clock, no oral hearing, and no FWD due date, because no trial exists. Set no PTAB alerts for this patent; set a docket alert on any newly-filed district court complaint naming it instead.

I'll research the assignment history for US 5566170. Let me start with the authoritative sources.

Let me dig into the litigation and corporate history angles.

Let me try to surface the actual USPTO assignment records and check for any post-issue transfers.

Ownership Reconstruction — US Patent 5,566,170

Application 08/366,221 · "Method and apparatus for accelerated packet forwarding" · Filed 1994-12-29 · Issued 1996-10-15 · Anticipated expiration 2014-12-29 (Expired – Lifetime)

Data-integrity note up front: I retrieved the Google Patents legal-events record and the litigation record (Fed. Cir. 329 F.3d 823), but I was not able to pull the USPTO Assignment Center abstract of title (reel/frame, correspondent) for this patent in this session. The single recorded assignment below is substantiated by the Google Patents legal-events entry; its reel/frame and correspondent are not in the source text I retrieved and I will not invent them. Where a field is unknown I say so rather than fill it.

Inventors

Unusual-pattern check: Only two inventors, both assigning to the same entity two months after filing — an entirely ordinary inventor-assignment-to-employer step, not a mass-departure or pre-fire-sale pattern. No evidence of inventors departing within 12 months of filing was found. No anomaly flagged.

Original assignee

• Entity named on the issued patent: Storage Technology Corporation ("StorageTek"), Louisville, Colorado. Google Patents also lists Network Systems Corp. as a current assignee of record (see timeline).
• Primary line of business: Data storage hardware and software — tape automation, disk subsystems, storage networking. Publicly traded (NYSE: STK); ~$2.2B revenue and ~7,000 employees in 2004.
• Did they ship a product embodying the claims? The specification describes the claimed "fast packet processor" (FPP) as a performance accelerator card (FPGA) sitting between the MAC and shared memory buffer, used in FDDI, Ethernet, and Token Ring interface products. That networking product line came to StorageTek largely via its 1995 Network Systems Corporation acquisition (NSC's HYPERchannel / bridge-router heritage). Whether a specific shipping SKU practiced the claims is not established by any record I retrieved — I am stating the specification's own product framing, not a verified product mapping. Unclear / inference.
• Current status: Defunct. Acquired by Sun Microsystems (announced June 2005, completed August 2005, $4.1B cash); Sun acquired by Oracle Corporation (2010-01-27); the line continues as Oracle StorageTek. Note StorageTek filed Chapter 11 in 1984 but emerged in 1987 — that bankruptcy is ~10 years before this patent and is irrelevant to this asset.

Assignment timeline

Total recorded assignments substantiated in my sources: one (plus the filing/grant/expiry events).

• 1995-02-27 (executed and recorded same date per legal-events listing) — Reel unknown / not retrieved
  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST (see document for details)
  • Assignor: FIORE, EDWARD J.; BAKKE, MARK A. (the inventors)
  • Assignee: NETWORK SYSTEMS CORP.
  • Correspondent: Not retrieved. I cannot name the recording attorney or firm from the sources available. Flagging as a gap, not a finding — the "repeat correspondent" signal below therefore cannot be scored.
  • Context: Inventor-to-employer assignment. This is the only recorded conveyance I can substantiate for this patent.

Subsequent events — not assignments, but ownership-relevant:

• 1995 — StorageTek acquired Network Systems Corporation (per StorageTek corporate history). This is the mechanism by which the '170 asset reached the entity named as assignee on the issued patent (1996-10-15). No reel/frame for a merger or chain-of-title record was surfaced — corporate acquisitions are frequently never recorded at the USPTO even though title passes by operation of law.
• 2005 / 2010 — StorageTek → Sun → Oracle. No assignment records to Sun or Oracle were surfaced. Notably, Google Patents still lists Storage Technology Corp. / Network Systems Corp. as current assignees — Google derives "current assignee" from recorded assignments, so the absence of a Sun/Oracle record is a meaningful (if circumstantial) indication that no post-1995 assignment was ever recorded against this patent.

If the Assignment Center in fact holds additional reel/frame records beyond the Feb-1995 entry, they did not surface in my retrieval and are not represented above. Please treat the single-entry chain as a floor, not a ceiling.

Timeline diagram

timeline
    title Ownership and assertion of US 5566170
    1994 : Filed by Bakke and Fiore
    1995 : Inventors assign rights to Network Systems Corp
         : StorageTek acquires Network Systems Corp
    1996 : Patent issues to Storage Technology Corp
    1999 : StorageTek sues Cisco for infringement
    2003 : Federal Circuit vacates in part
    2005 : Jury verdict for Cisco
         : StorageTek acquired by Sun Microsystems
    2010 : Sun acquired by Oracle
    2014 : Patent term expires

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT. The only recorded conveyance (1995-02-27) runs from the natural-person inventors to Network Systems Corp., an operating networking-equipment manufacturer — not to a licensing LLC. No "IP / Holdings / Ventures" suffix entity appears anywhere in the chain, and no registered-agent-service address is on record. No evidence of a single-purpose Delaware/Texas LLC.

2. Known asserter in the chain — NOT PRESENT. No assignee at any point matches the enumerated list (Acacia, Marathon, IV, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, Spangenberg entities) or any Unified Patents / RPX high-frequency-plaintiff designation that I could surface. StorageTek, Network Systems Corp., Sun, and Oracle are all operating companies.

3. Repeat correspondent across the chain — UNCLEAR / NOT SCORABLE. With only one recorded link and no retrieved correspondent field, recurrence cannot be tested. This is a data gap, not a clean negative. Do not read "not present" into this line.

4. Cascading transfers — NOT PRESENT. One recorded assignment across a 20-year term, executed two months after filing. That is the opposite of a chained-LLC cascade. The Sun/Oracle acquisitions are corporate events, not chained shell transfers, and were apparently never recorded.

5. Pre-litigation transfer — NOT PRESENT. The sole assignment (1995-02-27) predates the 1999 StorageTek v. Cisco filing by roughly four years — nowhere near the 6-month window. The patent was asserted by the same operating entity that had held it since acquisition.

6. Bankruptcy fire-sale — NOT PRESENT (for this patent). StorageTek's Chapter 11 was 1984, a decade before the 1994 filing, and it emerged in 1987; the patent was filed, issued, and asserted long after. No Chapter 7/11 sale of this asset was found. (Contrast the Kodak/Nortel/Polaroid pattern — not applicable here.)

7. Privateering — NOT PRESENT. This is the inverse of privateering. StorageTek asserted the '170 patent itself, as the operating patentee, against Cisco's NetFlow Feature Acceleration and MPLS technology. A privateering arrangement requires an operating company parking patents with an NPE that sues on its behalf; here the operating company sued directly, first in W.D. Wis. (1999), then N.D. Cal. C00-1176 (SI) after §1404(a) transfer, and it lost — the Fed. Cir. vacated the '170 noninfringement SJ (329 F.3d 823, 2003-05-13) on a preamble-limitation issue, but the June 2005 jury verdict went to Cisco.

8. Defensive aggregator (anti-NPE) — NOT PRESENT. The chain does not terminate at RPX, AST, LOT, Unified Patents, or OIN. It terminates (by operation of corporate acquisition, unrecorded) in Oracle Corporation, a large operating company. Inverse-signal read: the patent was never neutralized by a defensive aggregator — it was simply litigated to a defense verdict and then expired naturally.

Verdict

Operating-company assertion.

StorageTek — a publicly traded data-storage manufacturer (NYSE: STK) — held the '170 patent by way of its 1995 acquisition of Network Systems Corp. (the only recorded assignment being the 1995-02-27 inventor-to-NSC conveyance) and asserted it directly, in its own name, against Cisco Systems beginning with the 1999 suit that became Storage Tech. Corp. v. Cisco Sys., Inc., 329 F.3d 823 (Fed. Cir. 2003), tried to a 2005 defense verdict. There is no shell LLC, no asserter, no cascading transfer, and no pre-litigation flip anywhere in the record I could substantiate; the chain terminates at Oracle, an operating company, 11 years after the patent's 2014-12-29 expiration. The one honest caveat is the correspondent field, which I could not retrieve — that gap affects only signal 3 and does not change the verdict.

Verify at: https://assignmentcenter.uspto.gov/ (search patent number 5566170) and the Google Patents legal-events record at https://patents.google.com/patent/[US5566170A](/patent/US5566170A)/en — the latter is the source for the 1995-02-27 Network Systems Corp. assignment entry above.

Caveat on confidence: this verdict rests on a documented litigation record and a documented single assignment, both of which are solid. It does not rest on a full reel/frame abstract of title, which I was unable to pull. If a full-chain search of the Assignment Center surfaces additional reel/frame entries — particularly any post-2005 conveyance out of Oracle — the verdict should be re-run.

I'll research this systematically, starting with the patent itself and its citation records.

Let me get the specific citation records from the patent databases and USPTO.

Let me retrieve the formal citation list for US5566170 from the patent databases.

Research Summary — US 5,566,170

Important verification note up front: I was able to confirm the patent's identity, bibliographic data, and the prior art it discusses in its own text, but I was not able to retrieve the complete USPTO "(56) References Cited" list (the face-of-patent citation list) before exhausting my search budget. I therefore report (a) what is confirmed, (b) what is partially confirmed, and (c) what I could not verify — rather than reconstructing the citation list from memory or inference. Do not treat the list below as the exhaustive (56) list.

1. The patent itself (confirmed)

Source: https://patents.google.com/patent/US5566170/en

2. Prior art explicitly identified inside US5566170 (confirmed)

The single reference I can confirm as cited prior art is:

US 5,249,292 A — "Data packet switch using a primary processing unit to designate one of a plurality of data stream control circuits to selectively handle the header processing of incoming packets in one data packet stream"

• Inventor: J. Noel Chiappa
• Filed: 1989-03-31 (continuation of Ser. No. 332,530, filed Mar. 31, 1989, now abandoned)
• Granted: 1993-09-28
• 17 claims, 5 drawing sheets
• Source: https://patents.google.com/patent/US5249292

Why it is relevant here: US5566170 expressly reproduces Chiappa '292 as the "prior art network device 150" in FIG. 1 and describes it: a high-speed data packet switching circuit with a software-controlled primary processing unit 172, a plurality of network interface units 160/164/168, and a plurality of data stream control circuits ("flow blocks") 162/166/170. The primary processing unit processes the first packet of each new stream and then assigns the stream to a hardware flow block "without further processing by the primary processing unit." Chiappa's flow blocks include a pattern matching circuit (validity determination), header stripping circuitry, a counter/truncator (truncation + error signaling), and prepend circuitry (header modification) — see Chiappa claims 2–7.

Claims of US5566170 that Chiappa could be argued to bear on under 35 U.S.C. § 102:

Caveat: Because the applicant deliberately presented Chiappa '292 as the background art being improved upon, the examiner and applicant treated Chiappa as distinguished — the asserted novelty is adding "next operation information" to the media header based on only a portion of the PDU, so that downstream processing by the forwarding processor is reduced. Chiappa is therefore best characterized as the closest prior art / obviousness anchor rather than a clean § 102 anticipation of the independent claims. This is my technical analysis, not a legal conclusion of validity.

3. Related co-pending applications named in US5566170 (NOT prior art)

These are cross-referenced in the "Related Inventions" section, all filed Dec. 23, 1994, common assignee — they are siblings, not § 102 art:

• Ser. No. 08/366,225 — "Method And Apparatus For Accelerated Packet Processing," Geof Stone → issued as US 5,598,410 (1997-01-28).
• Ser. No. 08/366,226 — "Method And Apparatus For Radix Decision Packet Processing," Geof Stone.
• Ser. No. 08/366,227 — "Method And Apparatus For Virtual Switching," Ken Hardwick et al. → issued as US 5,550,816 (1996-08-27), Storage Technology Corp.

Source: US5566170 specification, "Related Inventions."

4. Forward citations (NOT prior art — provided only to avoid confusion)

Numerous later patents cite US5566170 (e.g., US 5,598,410; US 5,550,816; US 7,185,266; US 7,995,580; US 8,718,051; US 9,596,300; US 8,087,064; US 7,624,142). These are "cited by" references and are post-1996, so they are relevant to the patent's influence, not to its patentability.

5. What I could NOT verify (stated explicitly)

• I could not retrieve the full face-of-patent "(56) References Cited — U.S. Patent Documents" list for US5566170. Google Patents indicates a citation cluster for this family, but I did not obtain a reliable enumeration of every cited reference. Do not treat Section 2 as the complete prior-art citation list.
• I did not verify the assignee of US 5,249,292 (the retrieved record did not show it), so I have deliberately omitted it rather than guessing.
• Dates for the sibling applications are drawn from the patent text itself (Dec. 23, 1994), which differs by six days from the 08/366,221 filing date of Dec. 29, 1994 — I have reported both literally, without correction, per the interpretive rule.

If you need the authoritative and complete (56) list, the definitive sources to pull are: (1) USPTO PatentCenter / Public PAIR for application 08/366,221, and (2) the "Patent Citations" table on the Google Patents page (https://patents.google.com/patent/[US5566170A](/patent/US5566170A)/en) or the front page of https://patentimages.storage.googleapis.com/...US5566170.pdf. I can continue drilling into those specific listings if you'd like the remaining REFERENCES CITED entries enumerated one-by-one.

I'll ground this analysis in the actual prior art and claim language. Let me run several searches.

Let me pull the full claim language and the "References Cited" section for this patent.

Let me get the exact independent claim language and any examiner-cited references.

Obviousness Analysis — U.S. Patent No. 5,566,170 (Bakke & Fiore)

0. Scope, sources, and confidence caveats

Verified from the patent page (authoritative text supplied): Patent number US 5,566,170A; application Ser. No. 08/366,221; inventors Mark A. Bakke and Edward J. Fiore; filed 1994-12-29; granted 1996-10-15; original assignee Storage Technology Corp., with a 1995-02-27 assignment to Network Systems Corp.; status "Expired – Lifetime" with anticipated expiration 2014-12-29. The page flags participation in a first worldwide family litigation (Darts-ip family 23442139).

Prior-art material actually present on the page: The only reference named as prior art in the specification is U.S. Pat. No. 5,249,292 to J. Noel Chiappa, issued Sep. 28, 1993, depicted as FIG. 1 ("prior art network device 150"). The balance of the page's "prior art" content is Google's keyword extraction (protocol data unit, data unit, media, protocol, preprocessor) and the co-pending sibling applications identified in the "Related Inventions" paragraph (Ser. Nos. 08/366,225, 08/366,226, 08/366,227).

⚠️ Two things I could not verify and will not assert:

1. The page's "References Cited" and "Cited By" tables were not present in the fetched content, so I cannot give you the examiner-cited U.S. patent art of record by number. Any element-by-element chart of examiner art must come from the PDF or USPTO PatentCenter image file wrapper.
2. The verbatim text of claim 1 was not in the fetched content. My searches recovered claims 3, 9, 10, 12, 13, 14, 15, 17, 21, 23 and 24 from a secondary reproduction (sumobrain). I reconstruct claim 1 below from the abstract, summary, and the dependency pattern, and flag every inferred word.

⚠️ Textual inconsistency to preserve, not correct: The specification states the three sibling applications were "filed on Dec. 23, 1994" while also saying they were "all filed concurrently herewith." This application (08/366,221) was filed Dec. 29, 1994, and the sibling serial numbers (08/366,225–227) are numerically later than 08/366,221 — which corroborates a same-day (Dec. 29) filing and suggests the "Dec. 23" dates are typographical. Per your standing rule I have not auto-corrected them, but this 6-day gap controls whether those applications could have been 35 U.S.C. § 102(e) art, and it should be resolved against the file wrappers.

1. Governing law and effective date

• Filing date Dec. 29, 1994 → pre-AIA § 102/§ 103 applies (no AIA first-inventor-to-file or § 102(d) analysis).
• Framework: Graham v. John Deere, and KSR Int'l v. Teleflex (obviousness where a POSITA had a reason to combine, a reasonable expectation of success, and the combination yields predictable results). MPEP 2141–2144.
• § 103(c) (common-ownership disqualification) was added by the 1999 AIPA, generally applicable to applications filed on or after Nov. 29, 1999. This 1994 filing therefore very likely falls outside § 103(c)'s reach — I flag this as needing statutory/MPEP verification for the applicable vintage rather than asserting it. It matters because the sibling applications are commonly owned (Network Systems Corp.).
• § 103(b) is inapplicable (that subsection is biotechnology process claims).

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

For a Dec. 1994 priority date, a POSITA is a designer of LAN/WAN bridge-routers with: working knowledge of the OSI data-link and network layers; Ethernet and FDDI/Token Ring MAC framing (including LLC/SNAP/SAP encapsulation and the Token Ring Routing Information Field); IP header processing per RFC 791 (version/IHL, TTL, header checksum), DECnet and IPX/Appletalk addressing; IEEE 802.1D transparent bridging and source-route bridging; and hardware/firmware implementation experience (ASIC/FPGA, content-addressable memories, pipelined fast-path datapaths). Spanning Chiappa's architecture — a software primary processing unit plus hardware flow blocks — is squarely within that skill set.

3. The claims at issue (functional block-plus-format style; § 112 ¶ 6 applies to "means")

Reconstructed claim 1 (inferred wording in brackets): A protocol data unit preprocessor for use in a protocol data unit forwarding device [in a communication network] comprising: (a) identification means for determining media header information of a protocol data unit which is received from over the communication network; (b) validation means, operatively coupled to the identification means, for validating the media header information; and (c) modification means, operatively coupled to the identification means, for adding next operation information to the media header information based upon the determined media header information [such that subsequent processing of the protocol data unit by the protocol data unit forwarding device is reduced].

• Claim 3 — validation scheme selected from the group consisting of time-to-live, hop count, checksum, header type, header version, network header length, check options, source route header length, and duplicate LAN identifier check.
• Claim 9 — source-route bridge destination lookup: check for specifically routed PDU, find next LAN ID in the source route, compare to a predetermined list.
• Claim 10 — device selected from bridge, router, switch, inline filter, protocol converter, encapsulating device, security device; PDU = frame/cell/packet; media include voice/video/data.
• Claim 14 — the same three means plus a forwarding processor that forwards "based upon the next operation information."
• Claim 17 — pre-forwarding modification selected from decrement TTL, increment hop count, modify checksum, truncate PDU, remove FCS.
• Claim 23 — method in a first processor (determine media header info from a portion of the PDU, validate, add next operation information) then a second processor (forward per that information).
• Claim 24 — the designated next operation selected from route, bridge, source route bridge.

Two claim-construction points drive the whole analysis:

1. "Media header information" is defined by the specification as "at a minimum the encapsulation type, protocol type, frame type, media destination, and source route information." A reference must therefore be shown to determine L2 header content, not merely to parse a generic header.
2. "Such that subsequent processing … is reduced" is a functional result. If construed as a mere statement of intended result it adds little patentable weight (In re Schreiber line; MPEP 2114). It only bites if the claims are narrowed to the specific data structure — the 8-byte "receive info" (protocol ID, Bridge/Route bits, VFF bit, SA/DA CAM indices, SR Length, RII, Pad, Path hash, Encap).

4. Primary reference: Chiappa '292 (the patent's own FIG. 1 prior art)

Chiappa '292 — "Data packet switch using a primary processing unit to designate one of a plurality of data stream control circuits to selectively handle the header processing of incoming packets in one data packet stream" (17 claims) — discloses, with claim cites:

Critical admission against the patentee: the '170 specification itself states that "the Chiappa '292 patent describes a data packet switch 150 that operates at OSI layers 1 through 3 which provides a solution to many of the previously-mentioned problems." That is an applicant admission that the primary reference solves the very problem the '170 background recites (throughput at high packet and bit rates), and it severely undercuts any later argument that the art did not recognize or address the problem.

Where Chiappa '292 alone is thin: (i) it does not expressly disclose a content-addressable-memory lookup keyed on a network/media destination address; (ii) it does not expressly disclose the L2 classification set (encapsulation type, frame type, media destination type, source-route presence) mapped to a next operation of route / bridge / source-route-bridge; (iii) it does not recite the enumerated validation schemes of claim 3 or the TTL/hop-count/checksum modifications of claim 17.

5. Combinations that would render the claims obvious

Ground A — Chiappa '292 alone (§ 102 anticipation, or § 103 if a gap remains)

Map Chiappa cl. 7 (pattern match → header-end/validity acceptance → strip → truncate-check → prepend new header) onto the three means of claim 1 and claim 14. If "next operation information" is construed broadly as the forwarding information the flow block prepends to the packet, claims 1, 7, 12, 13, 14, 19, 21 and 23 fail under § 102; if construed narrowly as the '170 receive-info structure, claim 1 fails at minimum under § 103 as a design choice in data packaging (below, Ground F). This is the single most dangerous reference and the first one to brief.

Ground B — Chiappa '292 + IP router header-processing art (RFC 791 and the standard router fast path)

Covers claims 3 and 17 (TTL, header version/length, options, checksum; decrement TTL, modify checksum, truncate, strip FCS).
Motivation: Chiappa expressly designates the flow blocks to perform "packet forwarding processing to effect routing" ('292 cl. 14). A POSITA cannot route an IP datagram in 1994 without decrementing TTL and recomputing the header checksum, decrementing/incrementing hop counts for the other supported protocols, and validating version/IHL and header length — these are mandated by the protocol standards the router is obliged to implement. The result is purely predictable. This is the classic KSR situation: "a court must ask whether the improvement is more than the predictable use of prior art elements according to their established functions."

Ground C — Chiappa '292 + CAM-based route lookup

Covers claims 8 (address-lookup algorithms) and materially strengthens 9.
Secondary reference: McAuley, Francis & Motwani(‑style), "Fast Routing Table Lookup Using CAMs," Proc. IEEE INFOCOM, Mar.–Apr. 1993, pp. 1382–1391 (bibliographic record appears in the "Other References" list of US 8,718,051 via FreePatentsOnline). This is pre-1994 art teaching exactly the device Chiappa's architecture lacks: a CAM that returns a table index for a routing-protocol destination address at hardware speed.
Motivation: Chiappa's stated objective is to keep the primary processing unit out of the per-packet path; the known bottleneck for doing so was the address lookup. CAMs were the recognized hardware answer for that bottleneck, and '170's own specification treats the CAM as a conventional component ("a content addressable memory 128 (CAM)") that the software uses to "quickly get a pointer into a forwarding table without looking at the protocol data unit." A POSITA adding a CAM to Chiappa's flow block would be using a known element for its established function with a reasonable expectation of success.

Ground D — Chiappa '292 + IEEE 802.1D bridging and Token Ring source-route bridging

Covers claims 3 (source route header length; duplicate LAN identifier check), 9 (specifically-routed-frame detection, next-LAN-ID lookup), 10 and 24 (route / bridge / source route bridge classification).
Motivation: Chiappa is a multi-protocol bridge/router. Under 802.1D transparent bridging and the IBM/IEEE 802.5 source-routing specification, a bridge must read routing-control bytes, compute/validate the RIF length, reject odd-length RIFs, detect duplicate ring/bridge identifiers, and resolve the next LAN ID for specifically routed frames — for every frame. Because these are quintessentially "routine, repetitive" operations ('292 cl. 14), a POSITA would place them in Chiappa's high-speed flow block, exactly as '170 does, to relieve the software path. This is the most likely combination to dispose of claims 9 and 24.

Ground E — Chiappa '292 + the sibling applications (⚠️ weak; flag for the record)

Stone, "Method and apparatus for accelerated packet processing" (Ser. No. 08/366,225; granted as US 5,598,410 on 1997-01-28), the Ser. No. 08/366,226 "radix decision packet processing" application, and Hardwick et al., "Method and apparatus for virtual switching" (Ser. No. 08/366,227; granted as US 5,550,816 on 1996-08-27) are nominally the closest "art on the same problem." They are nevertheless poor § 103 references and should not be the centerpiece:

• They were filed concurrently with (or days after) this application, so on the face of it they cannot be § 102(e) art; and
• to the extent any earlier-effective-date sibling were § 102(e) art, common ownership to Network Systems Corp. would invite a § 103(c)-type disqualification argument — though, as noted in §1, § 103(c) may not reach a 1994 filing, so this must be checked.

Their real value is evidential (state of the art; family/priority and obviousness-type double-patenting exposure) rather than as § 103 art. Resolve the "Dec. 23 vs. Dec. 29" date question before relying on any of them.

Ground F — Chiappa '292 + routine engineering / design choice (KSR, MPEP 2144.04)

These are the fallback grounds for the "specific data structure" limitations, and they are strong:

• 32-bit/4-byte alignment and 0–3 bytes of padding of the prepended information: dictated by word-width of the shared bus and standard alignment practice; '170 itself justifies it only as a performance optimization. Mere design choice / predictable result.
• Field selection and packing in the 8-byte receive info (Protocol ID, Bridge/Route bits, VFF bit, SA/DA lookup indices, SR Length, RII, Encap, Pad, Path hash): "the arrangement of the receive info fields is a design choice obvious to one of ordinary skill." Claim 1 and claim 14 are silent on any specific field layout; the fields only appear in dependent/description material.
• FPGA implementation of the preprocessor: '170 says only that the FPP "is implemented as a performance accelerator card (e.g., a field programmable gate array (FPGA)) that attaches between the inbound interface MAC and shared memory buffer" — a selection among known hardware implementation options with predictable results.
• Placement of the preprocessor between the MAC and shared memory: a straightforward architectural placement given Chiappa's interconnecting means 156/174.
• First-processor/second-processor division (claim 23): Chiappa already teaches precisely this division of labor.

6. Dependent-claim disposition summary

7. What the patentee will argue, and how it fares

1. "Chiappa's prepended header is the outbound header, not 'next operation information' added to the media header." The strongest non-obviousness argument. It succeeds only if the tribunal adopts a narrow construction of "next operation information" tied to the receive-info structure — which then collapses into Ground F (design choice) and Grounds C/D.
2. "Chiappa assigns streams by CPU-selected flow block; '170 decodes every packet in the preprocessor from the first bytes." Chiappa cl. 14 already recites examining "at least a portion of each packet" by the hardware and determining acceptability from matched header bits, so this distinction is narrow.
3. Teaching away / long-felt need. The '170 background recites a long-felt need for throughput and disparages "faster processors / better software / multiprocessors." But teaching away must come from the prior art, not from the applicant's own background section — and the applicant's own admission that Chiappa "provides a solution to many of the previously-mentioned problems" is a self-inflicted wound.
4. Secondary considerations. The Darts-ip litigation flag indicates real commercial stakes, and nexus evidence (licensing, copying, industry praise, failure of others) could be developed. However, the specification discloses throughput improvement only in general terms; a nexus between the claimed three-means arrangement and any proved commercial success would need to be built from evidence, not from the spec's aspirations. At the 1996 grant, a § 103 challenger can point out that the claims' advance is architectural allocation, precisely the subject Chiappa already addressed.

8. What I would verify before filing any § 103 position

1. Pull the printed claims 1–26 and the file wrapper (USPTO PatentCenter) — identify the actual examiner rejections, the art cited in the "References Cited" list (absent from the fetched page), and any Rule 131/132 submissions or terminal disclaimers over the Stone '410 and Hardwick '816 siblings.
2. Verify the AIPA § 103(c) effective date for a 1994-filed application before relying on common ownership to disqualify anything.
3. Verify Chiappa '292's § 102(e) date (its filing was as a continuation of Ser. No. 332,530, filed Mar. 31, 1989, now abandoned; the granted patent issued Sep. 28, 1993 — a § 102(b) printed publication date that predates the Dec. 29, 1994 filing by more than a year, which makes the § 102(e) question moot for § 102(b) purposes).
4. Confirm the bibliographic record for "Fast Routing Table Lookup Using CAMs" (INFOCOM, Mar.–Apr. 1993) from the primary proceedings, not from a later patent's reference list.
5. Check the litigation record (Darts-ip family 23442139) for any prior invalidity ruling, IPR, or claim construction that already addressed these claims and Chiappa '292.

9. Bottom line

US 5,566,170 is highly vulnerable to a § 103 challenge, principally because its own specification designates Chiappa '292 as a prior-art packet switch that "provides a solution to many of the previously-mentioned problems," and because the claimed advance (a hardware preprocessor that parses/validates the L2–L3 header and prepends forwarding information so the software forwarding processor does less werk) is the same routine-repetitive-work-offload architecture Chiappa claims, with the remaining gaps supplied by (i) mandated protocol-standard header maintenance, (ii) conventional CAM address lookup, (iii) standard 802.1D/source-route bridging procedures, and (iv) routine design choices about field packing, alignment and FPGA placement. The best defense for the patentee is a narrow construction of "next operation information" tied to the disclosed 8-byte receive-info structure — which then hands the challenger Grounds C, D and F.

Verbatim note: any statements above about claims 1, 15, 16, 18–20, 22, 25 and 26 rest on reconstruction and the abstract/summary, not on text I retrieved; do not treat those as claim-text quotations.