US 6971028

I'll search for this patent number across the sources you mentioned.

Let me pull the claim set and check for any 2026 CAFC activity specifically involving this number.

Let me try to retrieve the actual claim text, since the provided full text omits the claims section.

Summary: US Patent 6,971,028 B1

Note on method: I searched for this exact identifier across the Google Patents full-text record, the USPTO-hosted patent PDF (patentimages), uspto.report, and general web/docket queries. I was unable to retrieve the verbatim claim text (the full text provided to me and the search snippets both stop before the "What is claimed is" section), and I found no CAFC 2026 docket activity for this number. I flag those gaps explicitly below rather than filling them in.

Bibliographic data (from the patent PDF front page and Google Patents)

Assignment chain as literally recorded (Google Patents; the record contains typographic variants, which I reproduce rather than correct):

• 2000-11-16 → Recourse Technologies, Inc.
• 2001-02-08 → Imperial Bank (security agreement)
• 2002-08-14 → "REOUCRSE TECHNOLOGIES, INC." (release of security interest; assignor Comerica Bank–California)
• 2003-01-10 → Recourse Technologies, Inc. (merger, Recourse Acquisition Corp.)
• 2003-03-04 → Symantec Corporation
• 2019-11-21 → CA, Inc.
• 2023-02-01 → adjusted expiration

Classifications: H04L63/1408, H04L63/1416 (network security / malicious-traffic detection and attack-signature event detection); G06F21/50, G06F21/55, G06F21/554.

Related applications named in the specification: 09/615,961 (denial-of-service protection), 09/615,888 (dynamically changing a computer port or address), 09/616,803 (quickly authenticating messages using sequence numbers) — all filed concurrently.

Abstract (verbatim)

"A system and method are disclosed for detecting and processing attacks on a computer network. Data indicating an attack may be taking place is received. The data is associated with an event. The data is placed in a selected one of a plurality of queues of data to be processed. The data in the queue is processed. Each queue is configured to store one or more sets of data, each set of data being associated with an event to be processed. An administrative domain may be notified that an attack may be taking place. The destination administrative domain may or may not be associated with other than the sending administrative domain. The source of an attack may be identified. Messages associated with an attack may be tracked back to identify a point of attack at which messages associated with the attack are entering a network."

Plain-language overview of the independent claims

Uncertainty flag: I could not obtain the verbatim claim language. The overview below is a good-faith reconstruction from the abstract, the Summary of the Invention, and the flowcharts (FIGS. 2–20). Specific claim numbers are not confirmed by me, so I describe the independent claims by subject matter rather than assigning numbers.

The abstract reads as a compressed restatement of the independent claims, and the specification's Summary of the Invention tracks it. Based on that, the independent claims appear to be directed to four distinct aspects:

1. Queued, metered attack-data processing (the core method and a corresponding system/computer-readable-medium claim).
   Receiving data indicating that an attack may be taking place; associating that data with an "event"; assigning the event to a selected one of a plurality of queues; and processing events out of the queues. The specification describes a 3×7 = 21-queue table (FIG. 6) indexed by MOD 3 of a hash of the destination address (row) and MOD 7 of a hash of the whole packet (column), read in a fixed rotating order with a five-second interval between dispatches to the analysis framework (FIG. 5). The stated purpose is defensive: an attacker flooding one destination with innocuous replicas to mask a real attack cannot starve analysis, because only one event per queue is dispatched per interval and events from other queues interleave.

2. Notifying / "handing off" information about an attack to another administrative domain.
   Identifying the correct recipient domain, determining whether that domain runs a compatible tracking system, and — if so — registering with it and sending a secure handoff message (certificate/X509 or X9.68-style compact certificate, signature, HMAC, and optionally S/MIME encryption), either directly, via a trusted third-party transaction server, or by encrypted e-mail to an RWHOIS-identified contact. Registration involves a hash-collision proof-of-work challenge (sender must find a number whose hash matches on at least ~20 bits) and Diffie–Hellman key/seed negotiation, to fend off denial-of-service and spoofing.

3. Identifying the source of an attack — e.g., using message data, cookie information, and RWHOIS lookups to identify the originating server or administrative domain, and reporting/tracking from there.

4. Tracking messages back to the "point of attack." Building a virtual topology map from a topology database, querying the node where the attack was detected to find the ingress port, and iteratively walking upstream (FIG. 10) until the port found is an external connection to another administrative domain — that port is declared the point of attack. If the upstream sub-network belongs to another tracking system in the same administrative domain, tracking can be handed to that system; a handoff to the source domain may then follow per policy.

Dependent claims (34 total, mostly not visible to me) appear to cover details such as: queue address calculation and scan order; event objects vs. incident objects and aggregation rules (baseline incident rate + two standard deviations, same attack type, same source address — FIG. 8); alerting by pager/e-mail; statistics, policy, topology, RWHOIS, configuration, log and token databases; third-party intermediation; rolling-window sequence numbers (40-byte window, 32-bit sequence numbers, ten valid numbers at a time, FIG. 20); and dynamic re-assignment of the handoff receiver port/IP address (FIG. 19) if the port is flooded or by schedule.

On the CAFC 2026 docket search — negative result

I ran targeted searches for "6971028" / "6,971,028" in combination with Federal Circuit / 2026 / appeal / litigation terms and returned no results tying this patent number to any 2026 CAFC docket or active litigation. Two points of caution:

• This is a null result, not affirmative proof of no activity. The general web searches I could run do not index CAFC dockets or PACER comprehensively; a dedicated Docket Alarm / PACER / CourtListener query would be needed to make a confident negative assertion.
• Practical context: the patent is recorded as expired as of 2023-02-01, which makes a live 2026 appeal unlikely — though an appeal from a pre-expiration infringement judgment or an IPR is not logically excluded by expiration.

I did observe this patent cited as prior art in other patents and in PTAB papers (e.g., as a reference cited on the face of US 8,347,383 and US 2019/0012456), and it appears to be the US member of a family that includes EP 1 203 280 B1, whose claim 1 recites the hash-collision authorization protocol (receive request to communicate, select random number N1, send hash, receive N2, compare hashes, process if a prescribed nonzero number of bits match). I'd treat the EP linkage as likely but not independently verified — I did not confirm the EP priority/INPADOC link from an authoritative family record, and one search result attributes a WO 2001/016709 (filed Aug. 30, 2000, published Mar. 8, 2001) to an inventor "Moran," which does not match the named inventors here and which I am therefore not asserting as this family's PCT.

Where I am not authoritative: verbatim independent-claim text and claim numbering, the precise independent/dependent split among the 34 claims, and any 2026 CAFC docket presence.

I'll search for litigation involving US patent 6971028 across patent litigation databases.

The initial results surfaced a different patent (6,987,102), which I'll exclude per the strict number-matching rule. Let me search more targeted sources.

Litigation Search: US Patent 6,971,028

Result: No litigation involving US Patent 6,971,028 was found in any of the sources searched.

What I searched

• General web searches for "6971028" patent litigation/lawsuit
• Targeted searches cross-referencing the patent's title ("System and method for tracking the source of a computer attack") and its original assignee (Recourse Technologies / Symantec)
• Attempts to locate records via litigation-aggregator sources (Unified Patents portal, CourtListener, PACER/CAFC-style results)

No docket, complaint, IPR/PGR, ITC action, or CAFC appeal naming 6,971,028 as an asserted patent appeared.

Important caveat on false positives

My searches repeatedly returned cases involving different patents whose numbers resemble but do not equal 6,971,028. Per the strict rule to interpret identifiers literally and not to return similar numbers, I have excluded all of these. They include (for transparency only, not as answers):

• U.S. 6,987,102 (Genzyme v. Zydus, D. Del. 1:16-cv-00540)
• U.S. 8,688,028 (StratosAudio v. Hyundai et al., W.D. Tex. 6:20-cv-01125 et al.)
• U.S. 6,971,028–adjacent "Xpoint" and Orthopaedic Hospital '028 patents

None of these are U.S. 6,971,028.

Context on the patent itself (from the authoritative patent text)

• Title: System and method for tracking the source of a computer attack
• Patent number: US 6,971,028 B1
• Application: US 09/615,676; filed 2000-07-14; granted 2005-11-29
• Priority date: 1999-08-30 (provisional 60/151,531)
• Original assignee: Symantec Corporation (originally Recourse Technologies, Inc.)
• Current assignee: CA, Inc. (assignment from Symantec, recorded 2019-11-21)
• Legal status: Expired – Lifetime; adjusted expiration 2023-02-01

Honest statement of confidence

I cannot confirm with high confidence that no litigation ever existed, because my searches did not return direct hits on litigation aggregators indexed specifically for this number. What I can state is: based on the sources searched, none of them disclosed any case involving US 6,971,028. The patent's expiry in February 2023 and its ownership by a large operating company (CA, Inc./Broadcom) rather than a litigious non-practicing entity make active assertion unlikely, but that is inference, not a documented finding.

If you need a definitive litigation history, the reliable next step is a direct query of:

• PACER (all district court dockets) filtered on the patent number in the complaint, and
• Unified Patents litigation portal and Docket Navigator / Lex Machina (subscription), plus
• USPTO PTAB (IPR/PGR/CBM) and ITC EDIS for Section 337 investigations.

These require direct database access that my web searches did not fully surface. I would not represent to a court or client that zero litigation exists without one of those authoritative database checks.

I'll verify the ODP baseline against public sources before concluding.

Let me drill down with targeted queries — including CBM (this is a pre-AIA patent) and any assignment-driven proceedings.

PTAB Proceedings — US 6,971,028 ("System and method for tracking the source of a computer attack")

Research note / confidence statement: The canonical source supplied for this task — the USPTO Open Data Portal structured "PTAB proceedings on file" block — returns no AIA trial proceedings for US 6,971,028. I ran independent web searches across PTAB decision repositories, IP Watchdog / Sterne Kessler PTO litigation reports, Docket Alarm, and general patent-docket aggregators for the patent number, its title, and its owners (Recourse Technologies → Symantec → CA, Inc.) and found no IPR, PGR, or CBM referencing this patent. I am therefore reporting zero proceedings as the primary conclusion, while flagging below exactly what I did surface so you can independently chase it. I did not find any proceeding I could name, so I have not invented one.

Proceedings overview

Total AIA trial proceedings on file: 0 (zero). Breakdown by status: 0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution denied. There is no IPR, no PGR, and no CBM for US 6,971,028. The bottom line for a defendant: the patent has never been tested at the PTAB, so its claims are wholly UNTESTED — not "hardened," but also not "dead." The single most powerful defensive fact is not a PTAB outcome at all: the patent is expired (adjusted expiration 2023-02-01), so any assertion today is limited to past damages inside the § 286 six-year lookback and cannot support prospective injunctive relief.

Because there are no proceedings to list in the per-proceeding format, I have instead applied that analytical frame to the closest things that exist (family, litigation, and reexam-adjacent history) and flagged them as unverified leads, not proceedings.

No proceeding to report — negative search result

• Type: N/A (no AIA trial filed)
• Filed: N/A
• Status: No PTAB activity on file (USPTO ODP structured data, most recent ingest)
• Judge panel: N/A
• Petition grounds: N/A
• Institution decision: N/A
• Final Written Decision: N/A
• Settlement / termination: N/A
• Appeal: N/A
• Defensive value: Neutral-to-favorable. No petitioner has generated estoppel, but no one has knocked out a claim either. You would be the first challenger, which means no § 315(e)(2) estoppel constrains you and no roadmap (no FWD claim constructions, no institution-stage claim-construction briefing) exists to guide you.

Lead worth chasing (NOT a PTAB proceeding) — SRI litigation over the ManHunt source code

• What it is: A District of Delaware docket surfaced in search results (gov.uscourts.ded.8551) whose exhibit lists include "SRI_Source Code Request to Symantec" and file paths such as /manahunt/src/java/com/recourse/manahunt/analysis/event/Trackback.java, EventCreator.java, ResponseEvaluator.java. These are the Recourse Technologies ManHunt product source files — the commercial embodiment of this patent family.
• Why it matters: If a full invalidity record (expert reports, invalidity contentions, source-code exhibits) exists in that litigation, it is the nearest thing to prior-art work product on this patent, and no IPR estoppel attaches to it because no IPR occurred.
• Confidence: Low on the specific linkage to 6,971,028. The exhibits reference "ManHunt" and Recourse source code generally; I could not confirm from the search snippet that US 6,971,028 was itself asserted. Treat this as an investigative lead, not a finding. Docket link surfaced via CourtListener RECAP: https://storage.courtlistener.com/recap/gov.uscourts.ded.8551.465.29.pdf

Family context (relevant to any future petition, NOT a proceeding)

The '028 patent (App. No. 09/615,676; priority 1999-08-30; filed 2000-07-14; granted 2005-11-29) has three co-pending siblings named on its face, each filed 2000-07-14 and each a separate potential target: 09/615,961 ("Protecting a computer network against denial of service attacks"), 09/615,888 ("Dynamically changing a computer port or address"), and 09/616,803 ("Quickly authenticating messages using sequence numbers"). If someone asserts the '028, check whether siblings are in suit too — the same petitioner-side prior art often maps across the family.

Strategic summary

Canceled vs. sustained vs. untested. Categorically: all claims are UNTESTED. No claim of 6,971,028 has ever been canceled, confirmed, or even instituted for review at the PTAB. When a patent has never been IPR'd, that is a genuine signal in both directions: it may mean it is a low-value/obsolescent asset nobody bothered to attack (consistent with a 1999-priority network-security patent that expired in 2023), or it may simply mean the right petitioner never had enough at stake. The Google Patents record shows the asset was re-assigned through Recourse Technologies → Symantec (2003-03-04) → CA, Inc. (2019-11-21) and carries a legal status of "Expired – Lifetime, expires 2023-02-01." Source: https://patents.google.com/patent/US6971028/en

Estoppel landscape. With zero IPRs, no § 315(e)(2) estoppel exists against anyone. For a defendant being asserted against today, that is entirely favorable: every § 102/§ 103 ground available on patents and printed publications remains available to you in an IPR, and — critically — you are not restricted to art that was "raised or reasonably could have been raised" by some prior petitioner, because there is no prior petitioner. The practical caveat is the flip side of no estoppel: you also have no prior FWD to lean on for claim construction, no SAS-style partial-institution roadmap, and you bear the full cost of building the record from scratch. Note also that CBM review is not a live option for this patent regardless of any filing window — CBM under AIA § 18 required claims directed to a financial product or service, and this patent is directed to network-intrusion detection and trackback, not finance; CBM also sunset on 2020-09-16. PGR is unavailable because the patent is pre-AIA (priority 1999-08-30). IPR is the only AIA vehicle — assuming a petitioner can show the patent is still being asserted with enough at stake to justify it.

Pattern signals. No serial-petitioner pattern exists (no petitioner at all). No patent-owner PTAB-appeal aggressiveness is observable, because the owner never had a PTAB case to appeal. There is no evidence of a defensive aggregator (e.g., Unified Patents) in the chain — Unified's typical model is to file IPRs against NPE-asserted patents, and its absence here, combined with the 2023 expiration, is consistent with the patent having fallen out of active assertion. The Recourse→Symantec→CA ownership chain and the ManHunt-derived litigation exhibits indicate this was a product-line patent asserted (if at all) in operating-company-versus-operating-company litigation, not a troll assertion vehicle — which further explains the absence of PTAB activity (operating companies settle or license rather than IPR each other's security portfolios).

Recommended next steps

1. Lead with expiration, not validity. The patent's adjusted expiration is 2023-02-01 per the Google Patents legal-status record. If a demand letter is citing 6,971,028 today, the demand is structurally defective as to prospective relief: no injunction, no ongoing royalty for post-expiration conduct, and damages confined to infringing acts within six years before the complaint under 35 U.S.C. § 286. Make this your first response and demand the plaintiff identify the specific past-accrual period.

2. No PTAB activity exists — say so plainly in any defense strategy memo. Because there is no FWD to quote and no disposition to point to, do not represent to a court or adversary that any claim has been canceled or sustained. The honest formulation is: "no claim of the '028 patent has been challenged or adjudicated at the PTAB." The absence is itself informative — a 1999 patent that reached expiration without a single IPR was almost certainly not a high-value assertion target.

3. If a live assertion nonetheless exists, verify the docket before building an IPR strategy. Confirm whether the SRI/ManHunt Delaware docket (gov.uscourts.ded.8551) actually asserted US 6,971,028. If it did, mine that record for invalidity contentions, expert reports, and source-code exhibits — that work product is cost-free input to a petition and carries no estoppel risk since no IPR was filed.

4. If you intend to file an IPR, act before the § 315(b) clock or the expiration math forecloses value. A one-year bar runs from service of a complaint alleging infringement; and with the patent expired, a successful IPR's only practical payoff is eliminating past-damages exposure. Model the cost of the IPR against the capped past-damages exposure before committing — for many expired patents the economics favor a § 286 damages challenge and license negotiation over a full PTAB trial.

5. Verify the negative result against a second structured source. Because the entire "no proceedings" conclusion rests on the ODP block plus my negative web searches, cross-check via the PTAB E2E / Patent Trial and Appeal Board End-to-End system and the USPTO Patent Center "Reviews" tab (https://patentcenter.uspto.gov) before relying on it in a filing. If you want, I can draft the exact query strings for a manual PTAB E2E search on patent number 6,971,028.

Sources consulted:

• USPTO Open Data Portal structured "PTAB proceedings on file" block (supplied; most recent ingest) — zero proceedings.
• https://patents.google.com/patent/US6971028/en — bibliographic, assignment, and legal-status data (granted 2005-11-29; expired 2023-02-01).
• CourtListener RECAP, D. Del. docket gov.uscourts.ded.8551 exhibit list (ManHunt/Recourse source code) — lead only, unverified as to the '028 patent: https://storage.courtlistener.com/recap/gov.uscourts.ded.8551.465.29.pdf
• Negative results from searches across PTAB decision materials, IP Watchdog PTO litigation reports, and patent-docket aggregators for the patent number, title, and assignees.

If you can tell me whether 6,971,028 has been asserted in a specific current litigation, I'll re-run the search with that case as an anchor — a live assertion is the single fact most likely to reveal a recently-filed IPR that the ODP ingest has not yet indexed.

I'll research the USPTO assignment record for this patent. Let me run targeted searches.

Let me dig deeper into the assignment specifics and corporate history.

Let me try to find the specific assignment records and check for any NPE assertion activity.

Assignment & Ownership Analysis — US 6,971,028 B1

Access note (read first). I attempted the USPTO Patent Assignment Search (assignment.uspto.gov / assignmentcenter.uspto.gov) and cross-referenced Google Patents legal-events, plainsite.org, and RPX/Unified-style aggregator queries. I retrieved the conveyance chain (types, assignors, assignees, recording dates) — this is mirrored both in Google Patents "Legal Events" and in the previously generated Bibliographic section. I did not retrieve the reel/frame numbers, execution dates, or correspondents of record for this chain; those fields did not surface in any indexed result I could reach, and the Assignment Center's own pages are not fully indexed by web search. I am flagging those as gaps rather than inventing values — this matters specifically for NPE signal #3 (repeat correspondent), which I therefore cannot score as "present." The chain itself is not blank; per the instruction "if no records, stop," I proceed because records exist.

Inventors

Unusual-pattern check: I found no evidence that either inventor departed the original assignee within 12 months of filing, and no evidence of a portfolio fire-sale tied to inventor departure. Note the corporate event that followed instead: Recourse was acquired by Symantec roughly two years after filing (announced July 2002). That is an ordinary M&A outcome, not an inventor-departure signal. Confidence: moderate — I did not obtain employment contracts, LinkedIn-style timelines, or PEDS correspondence data for either inventor, so "no departure" is a null result, not a verified negative.

Original assignee

Two layers must be distinguished, because the patent's prosecution and issue straddle an acquisition:

• Applicant/original assignee of the application: Recourse Technologies, Inc. (Redwood City, CA) — the inventors' employer, which took assignment of the application by 2000-11-16.
• Assignee named on the issued patent (2005-11-29): Symantec Corporation, Cupertino, CA — as recorded both on the front page and in Google Patents' "Original Assignee" field.

Product embodying the claims: Yes, through Recourse's product line. Recourse made ManHunt, a gigabit-speed, packet-analysis network intrusion-detection system, and ManTrap, a "honeypot" system. The claimed subject matter — real-time detection, queued/metered event analysis, dynamic port monitoring, and attack-source track-back — maps directly onto the ManHunt tracking architecture described in FIGS. 1–20. Contemporaneous reporting (The Register, Computerworld, NYT, InformationWeek, July 2002) describes ManHunt as deployed at ~150 customers including the U.S. Department of Energy.

Primary line of business: network intrusion detection / computer security software.

Current status: Recourse Technologies is dissolved as an independent entity — acquired, not bankrupt. Symantec agreed to buy it for $135M cash (announced July 17–18, 2002, alongside Riptech for $145M and SecurityFocus for $75M; $355M total). The merger was effectuated via Recourse Acquisition Corp. (see timeline, 2003-01-10). Separately, Symantec's enterprise/cyber-security business (the lineage relevant here) was acquired by Broadcom in 2019, and this patent's chain was assigned to CA, Inc., a Broadcom unit, on 2019-11-21. Confidence on the Broadcom/CA relationship: moderate — the 2019-11-21 assignment date is corroborated by Google Patents; the Broadcom–Symantec Enterprise corporate link is well-documented public reporting, but I did not pull the SEC filing or the underlying assignment instrument this session.

Assignment timeline

Caveat on format: I list recording dates (the only dates I could retrieve). Execution dates were not available. Reel/frame numbers are unavailable in this session — shown as [not retrieved] rather than fabricated. Correspondents are likewise [not retrieved].

• Recorded 2000-11-16 — Reel [not retrieved]

  • Conveyance: Assignment of Assignors' Interest
  • Assignor: LYLE, MICHAEL P.; MARICONDO, JAMES R. (as literally listed: "MARICONDO, JAMES R., LYLE, MICHAEL P.")
  • Assignee: RECOURSE TECHNOLOGIES, INC.
  • Correspondent: [not retrieved] — cannot assess recurrence; signal #3 remains unscored.
  • Context: Founder/inventor-to-startup assignment — the standard assignment of a newly filed application to the operating company that employed the inventors.

• Recorded 2001-02-08 — Reel [not retrieved]

  • Conveyance: Security Agreement
  • Assignor: RECOURSE TECHNOLOGIES, INC.
  • Assignee: IMPERIAL BANK
  • Correspondent: [not retrieved]
  • Context: Securitization / venture-lending collateral — Recourse pledged its IP as collateral for financing. (Consistent with a pre-IPO venture-backed startup; not an NPE signal.)

• Recorded 2002-08-14 — Reel [not retrieved]

  • Conveyance: Reassignment and Release of Security Interest
  • Assignor: COMERICA BANK–CALIFORNIA, as successor in interest to Imperial Bank
  • Assignee: "REOUCRSE TECHNOLOGIES, INC." (sic — the record contains this typographic variant; reproduced literally, not corrected per the strict-identifier rule)
  • Correspondent: [not retrieved]
  • Context: Loan payoff / lien release — the security interest was discharged (Imperial Bank was absorbed by Comerica). Housekeeping, not a transfer of ownership.

• Recorded 2003-01-10 — Reel [not retrieved]

  • Conveyance: Merger
  • Assignor: RECOURSE ACQUISITION CORP.; RECOURSE TECHNOLOGIES, INC.
  • Assignee: RECOURSE TECHNOLOGIES, INC.
  • Correspondent: [not retrieved]
  • Context: Internal M&A mechanics — the Symantec acquisition vehicle (Recourse Acquisition Corp.) merged into Recourse Technologies, leaving Recourse as the surviving entity. Prep step for the Symantec assignment below.

• Recorded 2003-03-04 — Reel [not retrieved]

  • Conveyance: Assignment of Assignors' Interest
  • Assignor: RECOURSE TECHNOLOGIES, INC.
  • Assignee: SYMANTEC CORPORATION
  • Correspondent: [not retrieved]
  • Context: Acquisition — formal transfer of the portfolio to the $135M cash acquirer; the operating-company-to-operating-company step.

• Recorded 2019-11-21 — Reel [not retrieved]

  • Conveyance: Assignment of Assignor's Interest
  • Assignor: SYMANTEC CORPORATION
  • Assignee: CA, INC.
  • Correspondent: [not retrieved]
  • Context: Divestiture / corporate reorg — transfer to CA, Inc. (Broadcom), coincident with Broadcom's 2019 acquisition of Symantec's enterprise security business.

(No further recorded assignments through the 2023-02-01 adjusted expiration per Google Patents legal events.)

Timeline diagram

timeline
    title Ownership of US 6971028
    1999 : Priority provisional filed 30 Aug
    2000 : Application filed 14 Jul
         : Assigned to Recourse Technologies
    2001 : Security agreement with Imperial Bank
    2002 : Security interest released
         : Symantec agrees to acquire Recourse
    2003 : Recourse merger recorded
         : Assigned to Symantec Corporation
    2005 : Patent issued 29 Nov
    2019 : Assigned to CA Inc a Broadcom unit
    2023 : Patent expired 1 Feb

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT. Every link in the chain runs through a named operating company: Recourse Technologies, Inc. (startup, 2000-11-16) → Symantec Corporation (2003-03-04) → CA, Inc. (2019-11-21). No "IP / Holdings / Licensing / Ventures" suffix, no registered-agent-service address, no single-purpose LLC anywhere in the recorded chain.

2. Known asserter in the chain — NOT PRESENT. No assignee in the chain appears on the enumerated NPE lists (Acacia, Marathon, IV, IPNav, Wi-LAN, Conversant/Mosaid, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Erich Spangenberg entities) nor did any Unified/RPX high-frequency-plaintiff query return this patent or its owners. The prior Litigation summary found no case asserting US 6,971,028, which independently corroborates the absence of an asserter.

3. Repeat correspondent across the chain — UNCLEAR (cannot score). This is the signal I most wanted, and it is the gap in my data: the Assignment Center's correspondent-of-record field was not retrievable for any of the six recorded events above. I therefore cannot state whether one attorney/firm handled multiple links. Per the task's own rule ("a single appearance is not a finding — the signal is recurrence"), I will not infer recurrence from nothing. Recommended next step: pull the six assignments' reels directly from Assignment Center and compare correspondents — this is the one check that could change the verdict.

4. Cascading transfers — NOT PRESENT. The transfers are spread across ~19 years (2000 → 2003 → 2019), each separated by years, with no chained LLCs and no sub-24-month sequence.

5. Pre-litigation transfer — NOT PRESENT. No infringement suit naming this patent was found (prior Litigation section), so there is no suit to anchor a 6-month pre-suit transfer to. The 2019-11-21 CA, Inc. assignment is a portfolio-wide corporate transaction, not a suit-enabling transfer.

6. Bankruptcy fire-sale — NOT PRESENT. Recourse was acquired for cash ($135M, Symantec, 2002–2003), not sold out of insolvency; Symantec sold the business to Broadcom as a going concern in 2019. No Chapter 7/11 appears in the record.

7. Privateering — NOT PRESENT. No evidence that Symantec or CA/Broadcom transferred this patent to an NPE to assert on its behalf; the last recorded transfer is intra-operating-company (Symantec → CA, Inc.).

8. Defensive aggregator (anti-NPE) — NOT PRESENT. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. It terminates at CA, Inc., a Broadcom operating company.

Verdict

Defensive / non-asserting. (Imprecise fit — see caveat.)

The recorded chain is a textbook operating-company M&A lineage — inventors → Recourse Technologies (2000-11-16) → Symantec (2003-03-04) → CA, Inc./Broadcom (2019-11-21) — with zero NPE signals present and the patent now expired (2023-02-01). Because the chain does not terminate at a defensive aggregator (RPX/AST/LOT/Unified/OIN) but at a large operating company, the "Defensive / non-asserting" label is an imperfect fit for the parenthetical definition; the operative predicate, however, is accurate: there is no evidence of any assertion or NPE involvement, so the patent is non-asserting in substance. The single unresolved item is NPE signal #3 (correspondent recurrence), which I could not score because the Assignment Center's correspondent fields did not surface — resolving it is the only check that could materially change this verdict.

Verification link: search by patent number at https://assignment.uspto.gov/patent/index.html (or https://assignmentcenter.uspto.gov/) and pull the six conveyance records above for reel/frame + correspondent of record.

Key unresolved gap, restated for the record: I could not retrieve reel/frame numbers, execution dates, or correspondents for any assignment in this chain. Nothing above should be represented as a verified reel/frame citation; the dates and parties come from Google Patents legal events, which mirror — but are not a substitute for — the USPTO Assignment Center record.

I'll search for the USPTO record and the cited prior art for US 6,971,028.

Let me try to retrieve the front-page "References Cited" list from the patent PDF and USPTO-based sources.

Answer: Prior-art citations for US 6,971,028 — what I could and could not retrieve

I was not able to retrieve the authoritative "References Cited" (front-page) list for US 6,971,028 within this session. I'm stating that up front because the core of your question — "look at each patent citation for 6971028" — depends on that list, and I will not invent it.

What happened: the authoritative full text you supplied begins at the Descriptions / Cross Reference section and the search-returned Google Patents snapshot likewise stops around the Background — neither includes the front page block that carries "(56) References Cited / U.S. Patent Documents / Foreign Patent Documents / Other Publications." Multiple targeted searches for the citation list (including "6971028" "References Cited", patentimages PDF, and uspto.report) returned either empty results or unrelated material. I hit the tool-step ceiling before I could pull the patentimages PDF front page directly.

Per the operating rules, I'm flagging this gap explicitly rather than reconstructing a plausible-looking list.

1. What I did verify (with sources)

The patent's identity is confirmed and was established in the previously generated sections (US 6,971,028 B1; App. 09/615,676; filed 2000-07-14; priority 1999-08-30 via provisional 60/151,531; Symantec, now CA, Inc.; expired 2023-02-01). I won't repeat that here.

Forward citations (documents citing 6,971,028) — verified from search results:

Critical framing: every one of these is later than 6,971,028. They are forward citations (evidence of the patent's technological relevance), not §102 prior art. A §102 analysis of 6,971,028 cannot rely on any of them. I include them only because they're the one citation-type dataset I could actually verify, and to prevent them being mistaken for the prior-art list you asked about.

I also saw a reference to EP 1 203 280 B1 (raised in the prior section as likely family member with a hash-collision authorization claim 1). Same family membership means it is not prior art to 6,971,028.

2. The decisive gap

I do not know, and could not verify, any of the following:

• Which U.S. patents or publications are listed under "(56) References Cited" on the 6,971,028 front page.
• Which foreign patent documents or non-patent literature (e.g., RMONv2 RFCs, Cisco SPAN/SMON documentation, Intrusion-detection conference papers) the examiner or applicants cited.
• Whether any cited reference was applied in a §102 rejection (which would name specific claims), versus merely listed.

Therefore I cannot provide "full citation, date, description, and which claim(s) it potentially anticipates" for the references you asked about. Any list I produced would be fabrication, and the strict-identifier rule you set makes a fabricated list worse than a null answer.

3. Candidate references a §102 analysis must check — labeled UNVERIFIED

So this section is useful rather than empty, here is the universe of art that a §102 analysis of this specific patent would need to examine. I have not verified that any of these appears on the face of 6,971,028, and I am not representing that they do. They are identified from (a) the patent's own background/description and (b) the well-known 1990s network-intrusion-detection corpus.

(a) Anchored in the patent's own text (so at minimum plausibly the subject of examiner citations):

• RMON / RMONv2 remote monitoring — cited by name in the spec as the mechanism used to read router ports.
• Cisco Systems' SPAN (Switch Port Analyzer) and SMON — cited by name as the switch-mirroring mechanisms.
• RWHOIS hierarchical network-information database — cited by name for attacker-entity lookup.
• S/MIME, X.509, ANSI X9.68 compact certificates, RSA PKCS #1 signatures, HMAC, Diffie-Hellman — named protocols bearing on the handoff/registration claims.
• General traffic logging at a fixed monitored node — the background art the patent disparages (as not real-time, not dynamically re-pointable).

(b) Contemporaneous network-security art whose title/subject matter overlaps the independent claims (verification pending):

• Systems directed to intrusion detection by monitoring network traffic (the class of Snort/TCPdump-adjacent and commercial IDS disclosures of 1996–1999).
• Network topology-mapping/trace-back disclosures — directly relevant to independent claim aspect #4 (iterative upstream port walking per FIG. 10).
• Firewall/adaptive-response disclosures — relevant to the "corrective action in real time" language.
• Proof-of-work / hash-collision client puzzles (Juels–Brainard / Dwork–Naor line of work) — directly relevant to the FIG. 16/17 registration protocol and to EP 1 203 280 claim 1.

I am deliberately not naming specific patent numbers from memory here, because I could not verify them against this patent's front page and the strict-identifier rule forbids substituting look-alike numbers. (Note for transparency: search noise repeatedly surfaced U.S. 6,987,102, 8,688,028, and trademark registration 6971028 — none of which is U.S. 6,971,028; also the trademark record itself uses "Registration Number 6971028," a genuine collision you should be aware of when searching.)

4. The §102 framework that applies once the list is obtained

For each reference actually cited on the face of 6,971,028, apply these filters — this is the analysis I would run, and it constrains what the answer can look like:

1. Date gate. The critical date is the 1999-08-30 priority date (provisional 60/151,531). A reference is §102 prior art only if it published/issued before 1999-08-30 (or, for §102(e), was filed before that date). References with post-1999-08-30 publication dates — including many that appear in the Google Patents "Similar Documents" and "Cited By" panels — are categorically unavailable.
2. Claim-by-claim, element-by-element. §102 anticipation requires every element of a claim in a single reference. The four independent-claim subject-matter groups are: (i) multi-queue, metered event processing; (ii) cross-administrative-domain handoff with registration/secure messaging; (iii) source-identification; (iv) iterative topology-based track-back to an ingress port. A reference anticipating (i) tells you nothing about (iv).
3. Claims are unknown to me. Per the prior section, the verbatim claim text was never retrieved. You cannot complete a claim-numbered §102 mapping without it. I therefore cannot say "reference X anticipates claim Y."

5. Exact next steps to close the gap (authoritative sources)

To get the actual prior-art list, query these directly — they are the sources my searches could not fully surface:

1. USPTO Patent Public Search / PatentCenter — record for 09/615,676. The "References Cited" and "Foreign References" fields, plus the file wrapper (which shows which references the examiner actually applied and against which claims). URL: patft.uspto.gov / patentcenter.uspto.gov.
2. The printed patent PDF front page — patentimages.storage.googleapis.com copy of US006971028.pdf, page 1, block (56). This is the fullest backward-citation list (examiner + applicant IDS).
3. Google Patents "Citations" tab for US6971028B1 (distinct from the "Cited By" tab) — but note it merges examiner and applicant citations and sometimes includes family members (e.g., EP 1 203 280), which must be excluded as non-prior art.
4. Espacenet / INPADOC for the family record, to separate true family members (EP 1 203 280 B1, WO 2001/016709 if confirmed) from cited prior art.
5. Global Dossier for the EPO counterpart's search report and citations — often richer than the U.S. front page.

Confidence statement

• High confidence: the patent's bibliographic data, status, and that the forward citations listed in §1 cite US 6,971,028.
• Zero confidence / explicit non-finding: the identity, dates, and §102 claim mapping of the references cited in US 6,971,028. I did not obtain that list, and I have deliberately not fabricated one.
• One possible contradiction to flag: the prior section notes a search snippet attributing a WO 2001/016709 to an inventor "Moran," which does not match Lyle/Maricondo. If WO 2001/016709 is actually this family's PCT, it would be a family member (not prior art) and the inventor attribution would need resolving. I could not verify either way.

I'll ground this analysis in the actual prior art cited on the face of US 6,971,028 and in the contemporaneous network-security literature, then map those references to each claim element.

I have the patent's own cited-references list. Let me pull the remaining claims and verify the substance of the key references.

Let me retrieve the full claim set and verify the substance of the core cited references.

Obviousness Analysis — US 6,971,028 B1 under 35 U.S.C. § 103

Builds on the prior sections. The earlier summaries flagged that the verbatim claim text was unavailable and that the 34-claim set was reconstructed. That gap is now partially closed for claim 1, which I retrieved verbatim from the USPTO Official Gazette record. Dependent claims 2–34 and any other independent claims remain reconstructed-from-specification, not verified. I say so explicitly at each point where it matters.

1. Methodology, sources, and honesty flags

Sources actually used

• Patent full text and bibliographic record: https://patents.google.com/patent/US6971028/en
• Front page (56) "References Cited" list (the "Prior Art section"): https://patentimages.storage.googleapis.com/9c/b4/2d/7897230e87b683/US6971028.pdf
• Verbatim claim 1 from the granted-patent Official Gazette (Issue 1300-5): https://webapp1.dlib.indiana.edu/virtual_disk_library/index.cgi/[5628977](/patent/5628977)/FID979/OG/html/1300-5/us06971028-20051129.html
• Cheswick SIR H1944 full text (confirmed as a firewall dongle reference, not a traffic-scoring reference): https://www.docketalarm.com/cases/[PTAB](/ptab)/IPR2015-01927/Inter_Partes_Review_of_U.S._Pat._7218923/docs/09-17-2015-Petitioner/Exhibit-1017-SIR_H1944.pdf

Flags (do not treat as verified):

• I obtained claim 1 verbatim only. Claims 2–34 are characterized by subject matter from the specification. Any claim-specific conclusion below about a dependent claim is provisional.
• I could not open the full text of most cited references (Ramakrishnan, Klaus, Conklin, Porras, Seaman, Zenchelsky, Day, Jackowski). Their characterizations rest on title, class/subclass, and examiner citation, and I mark each as [inferred] where so.
• The retrieved record contained a second cluster of patent numbers after the "Other Publications" block — 6,484,203, 6,499,107, 6,578,147, 6,647,400, 6,704,874, 6,708,212, 6,711,615 (all Porras/Gleichauf/Shanklin/Moran) and JP 2000174794 A. I cannot confirm whether these sit on the '028 face or are "cited-by" citations. Treat as unverified.
• No claim construction exists. The prior sections established zero PTAB proceedings and no verified litigation. This is a fresh, plain-meaning read of untested claims.

2. Governing standards

• Pre-AIA § 103 applies (priority 1999-08-30, provisional 60/151,531; actual US filing 2000-07-14).
• Critical date: for § 102(b) purposes, one year before the earliest US filing to which benefit is claimed → July 14, 1999 (if the provisional supports the subject matter) or July 14, 2000 if benefit does not reach back. Art published in the window between 1999-07-14 and 1999-08-30 is § 102(a) art only.
• KSR Int'l v. Teleflex (2007): a combination is obvious where the elements are known, the field is the same, and the combination yields predictable results — no explicit "teaching, suggestion, or motivation" is required. Graham v. John Deere factors govern.
• Design choice: selecting a table dimension, a scan order, or a scan interval is "a matter of design choice" absent evidence of a critical, unexpected result (In re Aller).
• Admitted prior art: a specification's own admissions count as prior art. The '028 specification expressly concedes that RMON version 2, Cisco SPAN, SMON, copy-port mirroring, and network management protocols for reading router/switch port statistics were all known: "the sniffer module must employ network management protocols such as the remote monitoring protocol version 2 (RMONv2) and switch copy port implementations such as Cisco System's Switch Port Analyzer (SPAN)." That is a powerful admission against the trackback and sniffer claims.
• "Whereby" clauses are presumptively non-limiting unless they give the claim "life and meaning" (Texas Instruments v. ITC; Hoffer v. Microsoft). The claim-1 "whereby a critical set of data … is timely selected" clause should be argued non-limiting — but I analyze it as if limiting, below, because a court might.

PHOSITA: B.S. in electrical engineering or computer science plus 2–4 years' experience in network security engineering / intrusion detection, or an M.S. with equivalent experience. Such a person knows: TCP/IP, packet capture on mirrored switch ports, IDS signature matching, RMON/SNMP, hashing for flow/table lookup, round-robin and fair-queueing schedulers, public-key cryptography (X.509, Diffie–Hellman), HMAC, S/MIME, and anti-replay sliding windows.

3. The prior art of record on the '028 face

Post-dating art that is not available (important negative): the published IP-traceback literature — Savage et al., "Practical Network Support for IP Traceback" (SIGCOMM 2000); Savage et al., "Tracing Anonymous Packets to Their Approximate Source" (LISA 2000); Bellovin's ICMP-traceback drafts (2000); Snoeren et al., hash-based IP traceback (2001) — post-dates the 1999-08-30 priority date and cannot be used. This materially affects the trackback claims (§ 7 below).

4. Independent claim 1, verbatim, and the primary ground

Claim 1 as granted (typo reproduced from the Official Gazette):

1. A method for detecting and processing attacks on a computer network, comprising:
receiving a plurality of successive sets of data each set each set being associated with a corresponding security event associated with the computer network;
placing each set of data in a selected one of a plurality of queues based at least in part on a queue selection algorithm by which sets of data associated with related security events are grouped into the same queue while sets of data associated with unrelated security events are spread across different queues; and
processing the sets of data by: (1) selecting for processing a first set of data from a first queue; (2) selecting for processing a next set of data from a next queue in order that contains a set of data; and (3) repeating step (2) until no queue contains a set of data that has not yet been selected for processing;
wherein the queue selection algorithm includes performing a first computation on a first at least a portion of the set of data to obtain a first index, performing a second computation on a second at least a portion of the set of data to obtain a second index, and selecting a queue for the set of data being processed based at least in part on the first and second indices, such that sets of data having the same values for both the first at least a portion of the set of data and the second at least a portion of the set of data are placed in the same queue;
whereby a critical set of data associated with a critical security event is timely selected for processing even under circumstances in which numerous sets of data associated with a corresponding set of security events that are related to each other but not to the critical security event are received prior to the critical set of data being received.

Observation on claim scope. Despite the "computer attack" title, claim 1 is a queue-scheduling claim, not a security-techniques claim. Its only security content is label-level: the queued items are called "security events." Everything else is (a) multi-queue classification by two computed indices, (b) round-robin service skipping empty queues, and (c) a functional "whereby" result. All three are classic scheduling constructs.

Ground 1A — Claim 1 obvious over Ramakrishnan (US 6,049,546) in view of Knuth (TAOCP vol. 1, pp. 234–238) and Durst, further in view of Klaus (US 5,892,903) or Conklin (US 5,991,881)

Motivation to combine (KSR): (i) all references are in the same field of endeavor — network traffic management and security monitoring; (ii) the combination is "the mere arrangement of old elements, each performing the function it was known to perform" (hash classification performs classification; round-robin performs fair service); (iii) there is an articulated, art-recognized need — do not let a burst at one destination starve analysis of unrelated traffic — which is the natural problem to which round-robin hashing is the natural answer; (iv) reasonable expectation of success is high, because the components are deterministic and compose without interaction.

Ground 1B — Alternative: Knuth + Cheswick H1944 + Durst, optionally + Durst/Lippmann

For a petitioner who prefers art of record with confirmed content, Cheswick (confirmed to teach a security device that applies security measures to an incoming stream, detects/suspects violations, and acts on identified packets) can supply the security-event context, with Knuth supplying the queue-selection and round-robin service. The combination motivation is identical.

Ground 1C — Anticipation-flavored fallback under § 102

If a single reference turns out to disclose hash-bucketed round-robin queue service applied to monitored traffic (Ramakrishnan is the best candidate on the face), claim 1 is anticipated under § 102(b)/(e). I cannot confirm this without the reference's full text — flag.

Bottom line on claim 1: it is likely invalid under § 103. Its novelty is concentrated in the two-index queue-selection arithmetic, which is the single most thoroughly predictable element in the whole claim.

5. The other independent claims

The abstract reads as a compressed restatement of four independent aspects (the earlier summary identified these). Each collapses to a combination of known elements:

(a) "Handoff to another administrative domain" claim family. Elements: identify recipient domain; determine whether it has a compatible system; register; send a secure message (certificate, signature, HMAC, optional S/MIME encryption); optionally via a trusted third-party intermediary.

• Ground 2A: Holden (6,067,620) and/or Zenchelsky (6,233,686) and/or Day (6,311,274) for secure networked communication and key management, in view of Durst/Lippmann and the SRI DERBI cooperative-IDS materials for the inter-organizational alert-sharing purpose, in view of Klaus/Conklin/Porras for the alert content.
• Ground 2B — the strongest sub-combination: the hash-collision proof-of-work registration protocol (sender must find n whose 160-bit hash matches ≥20 bits of a challenge) is materially the same construct as Hashcash (Adam Back, 1997) — a documented 1990s proof-of-work designed precisely to make a requester, and not the recipient, bear the computational cost of an unsolicited message. Combining Hashcash-style proof-of-work with a Diffie–Hellman key exchange and an X.509 certificate (all standard by 1999) to gate a peer security-alert channel is a textbook predictable composition. HMAC is RFC 2104 (Feb. 1997) — and the '028 recites "HMAC" by name as a known construct. S/MIME is RFC 2311/2633 (1998/1999). IPsec's IKE (RFC 2409, Nov. 1998) already used anti-clogging cookies for exactly the DoS-protection purpose.
• Motivation: inter-organizational incident sharing was the well-established mission of FIRST (Forum of Incident Response and Security Teams, founded 1990) and the CERT/CC advisory model; automating it over a secure, peer-authenticated channel is the predictable next step. And the '028 specification itself frames the motivation (attackers route through other domains).

(c) "Identifying the source of an attack" claim family (message data, cookie information, RWHOIS lookups to find the responsible party).

• RWHOIS is RFC 1714 (1994) — an existing hierarchical registry lookup. Using registry data to identify a responsible administrative contact is the reference's stated purpose, and Cheswick/Klaus/Conklin supply the attack identification. Ground: obvious over Conklin or Klaus in view of RWHOIS (RFC 1714); motivation is the reference's own purpose.

(d) "Tracking back to the point of attack" claim family (topology map → query node for ingress port → iterate upstream until an external connection is found → that port is the point of attack).

• Ground 3: Seaman (US 5,790,808) for automated network topology determination, in view of the expressly admitted RMONv2 / SPAN / SMON port-mirroring and port-statistics techniques, in view of Klaus/Conklin for attack detection.
• Motivation: once an administrator knows an attack is arriving at switch 108a, and knows (i) the network's connection topology (Seaman) and (ii) how to read per-port traffic statistics on each upstream device (RMON/SNMP, admitted), then iteratively repeating "which port is this traffic entering on?" hop-by-hop until the traffic appears from outside the domain is the straightforward, indeed the only sensible, manual procedure a network engineer would follow. KSR's "obvious to try" and "finite number of identified, predictable solutions" rationales apply directly.
• Weakness of this ground: it is a combination of art of record plus admissions, and the resulting claim has more "inventive feel" than claim 1 (see § 7). It is defensible but not airtight.

6. Dependent claims — grouped grounds

Reminder: claims 2–34 are not verified text. The grounds below follow the specification's disclosure and the earlier reconstruction.

7. Where the patent is most likely to survive — and where the record is weakest

In candor, three points cut against invalidation and should be stated rather than buried:

1. The FIG. 10 trackback claim is the hardest. The '028 is genuinely early in the traceback field — the published IP-traceback literature is all 2000–2001 and therefore unavailable as prior art. Invalidating the iterative-upstream-walk claim requires building it out of Seaman (topology) + the specification's own RMON/SPAN/SMON admissions + Klaus/Conklin, and then arguing KSR "obvious to try." That is a workable but contestable ground, not a slam dunk.

2. The queue-selection reasonableness hinge. A patent owner will argue the specific two-index scheme (distinct portions → distinct indices → combined address), with its security-specific "critical event must not be starved" purpose, is not what Knuth/Ramakrishnan taught. The response is that the purpose does not change the mathematics, and KSR forbids requiring the prior art to disclose the purpose — but expect this to be the fight over claim 1.

3. Prosecution history may be dispositive and I could not obtain it. The granted claim 1 is written in "security event," two-index, "whereby"-clause language that reads like the product of an amendment over art. If the applicant narrowed claim 1 by adding the two-index limitation to overcome a specific reference, that amendment likely originated in an examiner's § 103 rejection — and the examiner's own cited references, plus the reasons for allowance, are the single most valuable untapped input to any invalidity position. I could not retrieve the file history.

Correspondingly, I should flag a risk in my own analysis: my characterizations of Ramakrishnan, Klaus, Conklin, Porras, and Seaman are [inferred] from class, title, and examiner citation. Any one of them may disclose more or less than I have assumed. None of the grounds above should be filed or relied upon without reading the references.

8. Summary conclusion

Practical upshot for a defendant: the highest-value § 103 attack is on claim 1 and its scheduling dependents, where the art-to-claim fit is tightest and the prior art is unambiguously pre-critical-date (§ 102(b) Knuth; § 102(e) Ramakrishnan and Cheswick). Because the prior sections established that no IPR has ever been filed and no § 315(e) estoppel exists, all of these grounds remain fully available in the first IPR any petitioner files. The catch remains the expiration math flagged earlier: with adjusted expiration 2023-02-01, the payoff of an IPR is limited to extinguishing § 286 past-damages exposure, so model the cost against that exposure before filing.

Next steps I would take, in order: (1) obtain the prosecution file history and the examiner's reasons for allowance — that identifies the exact reference the claim was narrowed over; (2) pull the full texts of Ramakrishnan, Klaus, Conklin, Porras, and Seaman to replace my [inferred] characterizations with verified disclosures; (3) verify whether the Porras/Gleichauf/Shanklin cluster is on the '028 face; (4) build a formal claim chart for claim 1 against Ramakrishnan + Knuth as the primary IPR ground, with the trackback claims reserved for a second ground under KSR "obvious to try."

Cited URLs: https://patents.google.com/patent/US6971028/en · https://patentimages.storage.googleapis.com/9c/b4/2d/7897230e87b683/US6971028.pdf · https://webapp1.dlib.indiana.edu/virtual_disk_library/index.cgi/5628977/FID979/OG/html/1300-5/us06971028-20051129.html · https://www.docketalarm.com/cases/PTAB/IPR2015-01927/Inter_Partes_Review_of_U.S._Pat._7218923/docs/09-17-2015-Petitioner/Exhibit-1017-SIR_H1944.pdf · http://patentimages.storage.googleapis.com/4e/2a/0b/30e4298ca4e68d/USH1944.pdf