US 7814546

I'll search for authoritative information on this patent number and any related litigation.

Let me run additional targeted searches.

US Patent 7,814,546 — Search Results and Summary

Important note on search scope: I was able to retrieve the patent document itself (Google Patents, plus the USPTO/EPO-derived bibliographic data and the BBN-related family citations). My searches, however, returned no results whatsoever for any CAFC 2026 docket, district court case, IPR, or PTAB proceeding involving US 7,814,546. Several search queries against litigation databases came back empty or matched unrelated patents (e.g., 7,844,915, 7,519,814). I therefore cannot confirm either the existence or the non-existence of litigation — I simply have no authoritative evidence of any CAFC 2026 appeal for this number. Treat the litigation portion of this answer as "not found," not as "confirmed absent."

Bibliographic Data (from the patent front page)

Note one literal-reading point: the normal 20-year term from the March 10, 2005 filing would have expired March 10, 2025; the listed "adjusted expiration" of April 30, 2028 reflects patent term adjustment. The page also lists a "Verizon Patent and Licensing Inc." 2014 assignment and a "RTX BBN Technologies, Inc." 2024 change-of-name, consistent with dual ownership.

Abstract (verbatim)

"A system and method for determining the point of entry of a malicious packet into a network is disclosed. An intrusion detection system detects entry of the malicious packet into the network (500). A stepping stone detection system identifies stepping stones in extended connections within the network (524). A traceback engine isolates the malicious packet in response to operation of the intrusion detection system (528), wherein the traceback engine utilizes the identified stepping stones to determine the point of entry of the malicious packet."

Independent Claims in Plain Language

Claim 1 — System (integrated IDS + stepping-stone detector + traceback engine). A system with three cooperating parts: (a) an intrusion detection device that detects the malicious packet entering the network; (b) a stepping stone detection device that detects stepping stones in extended connections, identifies correlated connection pairs, and produces a table of connection pairs; and (c) a traceback engine that, in response to the IDS, generates a query containing identifying information about the malicious packet, forwards it to certain routers (which generate their own representations of forwarded packets and answer whether the malicious packet passed through them), then uses the connection-pair table to look up a previously received "representative packet" from the incoming connection correlated with the malicious packet's outgoing connection, and uses that representative packet to determine the point of entry. The novel hook is the coupling: traceback output feeds a stepping-stone lookup table, and the correlated incoming connection's representative packet is used to continue the trace.

Claim 8 — Method (packet → router query → stepping-stone correlation → point of entry). At the traceback engine: receive the target packet from the detection device; send a query identifying the target packet to a first network component (router) and get a reply; process it; send a second query to a second component to identify correlated connections according to a table of correlated connection pairs; receive a reply that includes a previously received representative packet from an incoming connection correlated with the target packet's outgoing connection; process it; and determine the point of entry from that information.

Claim 16 — Non-transitory computer-readable medium. Instructions for: generating a query with information about at least a portion of the intruding packet (created by the traceback engine in response to a triggering event from the IDS); transmitting it to a network component; receiving a reply in which the component matches its stored packet representation to the query and indicates source/destination addresses; generating a second query with the intruding packet's outgoing connection information; transmitting it to a second network component; and receiving a reply identifying an incoming connection correlated to that outgoing connection per a table of identified correlated connection pairs, along with a previously received representative packet and its time-last-seen. The "last packet seen / time last seen" element matters because traceback evidence (Bloom-filter digest tables) ages out.

Claim 17 — Method (packet-digest-based traceback + connection-pair table). Process a triggering event to extract target-packet information; generate and send a query containing a representation of part of the target packet; receive a reply based on at least one packet digest produced as packets are forwarded, including outgoing connection information for matching packets; then generate a second query with the outgoing connection information, send it to a second network component, and receive a second reply indicating an incoming connection previously associated with the outgoing connection according to a table of identified correlated connection pairs; use that to identify the intrusion location. This is the claim that most explicitly ties the stepping-stone correlation to digest-based (SPIE-style) packet auditing.

Claim 21 — Method (end-to-end SPIE workflow). The longest and most workflow-specific claim: at a Source Path Isolation Engine traceback manager (STM), receive a traceback request from an IDS in the form of packet P, victim V, and time of attack T; dispatch a query with P, V, T to the SCAR (SPIE Collection and Reduction Agent) for V's region; the SCAR polls each SPIE-enhanced router with a Data Generation Agent (DGA); receive replies indicating whether P was seen; mark replies as active path data; build a source path trace; forward the source path tree to the STM with the region-entry time T′ and the entering packet P′; attempt to identify the ingress point; if it can't, expand one hop outward using P′, the border router as V′, and T′; have a stepping stone detection process produce a connection-pair table; trace P′ to the router nearest an ingress point that is a stepping stone host; query the connection-pair table to get the next connection, a new target packet, its last-seen time, and last router; and construct a new query to continue the trace. Of note, this claim recites the specific SPIE component names (STM, SCAR, DGA) as claim elements.

Claim 22 is dependent on claim 21 and merely adds that victim V is expressed as the last-hop router, not the end host.

Dependent claims 2–7, 9–15, 18–20 add details such as the table's fields (IP addresses, ports, representative packets, time last seen), hop-by-hop propagation and negative replies, the query to the connection-pair table when no router reports the packet, treating the detection device as part of the traceback engine, the DGA's stored time-stamped digest tables, and the Bloom filter with k hash functions (claim 20 — note the patent text literally says the filter "computers k distinct packet digests," a typographical error in the printed claim).

Caveats / Uncertainty

• Litigation: I found no CAFC 2026 docket, appeal, IPR, or infringement suit referencing 7,814,546. I could not directly query the CAFC docket system or USPTO PatentCenter/assignment records in this session, so this is an absence of evidence, not proof of absence. If you need a definitive litigation check, it should be verified against PACER/CAFC dockets and USPTO PatentCenter directly.
• Assignment history: The front page shows a chain of BBN-related reassignments (security interests, mergers, name changes), so "assignee" depends on the date of record; the current listed owners are Verizon Patent and Licensing Inc. and RTX BBN Technologies Corp.
• The search results I did obtain (Google Patents, patentimages PDF, Unified Patents portal, a Golden wiki mirror) all corroborate the patent text supplied and did not contradict it, so no conflict rule was triggered.

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

Let me try additional targeted searches.

Litigation Search: US Patent 7,814,546

Bottom line: I found no known litigation involving US Patent 7,814,546.

What I searched

I ran queries against litigation-oriented sources, including:

• General web search for the patent number in litigation contexts (US patent 7814546 litigation, "7814546" patent lawsuit defendants, patent 7,814,546 infringement case)
• Assignee-based queries (Verizon patent 7814546 assertion, "7,814,546" BBN Technologies Verizon lawsuit)
• Unified Patents portal query (unifiedpatents.com 7814546)

Results

None of these searches returned any case in which US 7,814,546 was asserted, challenged (e.g., IPR/PGR), or otherwise at issue. The only results returned were false hits on different patents with similar-looking numbers, which I am flagging rather than counting:

1. VirtaMove, Corp. v. Hewlett Packard Enterprise Company, E.D. Tex., No. 2:24-cv-00093 (JRG) — asserted US 7,519,814, not 7,814,546. (CourtListener)
2. IP Bridge v. Ericsson (E.D. Tex., No. 2:21-cv-00213) and IP Bridge v. Nokia (No. 2:21-cv-00215) — asserted US 8,526,546, not 7,814,546. (RPX)

These are different patents and should not be attributed to 7,814,546.

Caveats on this finding

• I could not directly query PACER, the CAFC docket, or Unified Patents' litigation case list for this specific patent number. My searches returned no records, but "no search results" is weaker evidence than an authoritative "no cases on file" confirmation from those systems.
• To be certain, the definitive checks would be: (a) the Unified Patents patent page/docket search for 7814546, (b) Docket Navigator or Lex Machina patent-number search, and (c) a PACER party search on the current assignees.

Context that may explain the absence of litigation

From the patent record itself:

• Original assignee: Verizon Corporate Services Group Inc. / Raytheon BBN Technologies Corp. (now RTX BBN Technologies, Inc.); one interest also held by Verizon Patent and Licensing Inc.
• Patent type: US 7,814,546 B1, "Method and system for integrated computer networking attack attribution," filed 2005-03-10, priority 2004-03-19, granted 2010-10-12, adjusted expiration 2028-04-30 (now well expired/expiring).
• Government interest: made with U.S. Government support under NSA contract No. N66001-00-8038.
• Its subject matter (IP traceback + stepping-stone detection) is defensive infrastructure technology held by operating companies rather than a classic NPE assertion target, which is consistent with there being no recorded infringement suits.

Confidence: Moderate-to-high that no litigation exists as of today's date, but I want to be explicit that this conclusion rests on the absence of search hits rather than a positive verification against PACER/CAFC/Unified Patents docket data, which I was unable to complete.

If you'd like, I can attempt further targeted searches (e.g., on "RTX BBN Technologies" litigation, or Verizon Patent and Licensing patent assertions) to cross-check.

I'll verify the structured "no proceedings" signal with targeted searches before writing up.

No hits yet. Let me check docket aggregators and the patent's assertion history specifically.

Let me do a final sweep across litigation/PTAB docket databases and the related BBN family.

PTAB proceedings overview

Total AIA trial proceedings on file for US 7,814,546: zero. The structured "PTAB proceedings on file" block — sourced from the USPTO Open Data Portal — reports no IPR, PGR, or CBM for this patent, and I could not surface any unindexed or older proceeding through web search of PTAB-related dockets and aggregators. There is therefore no breakdown by status to report: no active proceedings, no claims invalidated, no claims sustained, no settlements, and no institution denials. Bottom line for a defendant: the patent has never been tested at the PTAB, so claim 1 and every other claim stand unadjudicated and fully enforceable on their face — but equally, none of the hardening that comes from surviving an IPR has occurred, and no petitioner has burned prior art or triggered estoppel. That is a materially better setup for a defendant than facing a patent that has already beaten two IPRs.

Proceedings

None. No AIA trial proceeding has been instituted, denied, or terminated against US 7,814,546.

For completeness, the following items were checked and are not proceedings on this patent:

• IPR2025-00464 / IPR2025-00465 / IPR2025-00466 (Padagis US LLC v. Neurelis, Inc.) — challenges U.S. 8,895,546, 11,241,414, and 11,793,786. The "546" suffix is a false friend. Different patent (alkyl glycoside/neuroscience), different owner, different field. Do not cite these as this patent's proceedings.
• IPR2018-00274 — challenges U.S. 7,834,586, not 7,814,546. Also a false friend.
• US 6,981,158 and US 7,200,105 — BBN Technologies patents cited as prior art against the '546 patent. They are references in the '546 file history, not trial numbers.

Related family / prior-art context (not PTAB proceedings)

• Filing: 2005-03-10 (application 11/077,400); priority: 2004-03-19 (provisional 60/554,370).
• Granted: 2010-10-12.
• Status: Active; adjusted expiration 2028-04-30 (i.e., the patent is still in force for roughly another 20 months from today's date of 2026-09-11 — it is not an expired patent you can safely ignore).
• Current assignees: Verizon Patent and Licensing Inc. and RTX BBN Technologies Corp. (formerly Raytheon BBN Technologies Corp.). Original assignee: Verizon Corporate Services Group Inc. / Raytheon BBN Technologies Corp.
• Source of record: https://patents.google.com/patent/US7814546/en

Strategic summary

Claim status. Because there has been no PTAB trial, no post-grant review, and (so far as public sources show) no district court invalidity judgment reducing this patent to judgment, the claim landscape is entirely UNTESTED. That is not the same as "valid" — it means claims 1–22 (including independent claims 1, 8, 16, 17, and 21) carry a statutory presumption of validity under § 282 and have never been subjected to an adversarial claim-construction or patentability ruling. There are no surviving-claims / canceled-claims lists to give you. If your demand letter quotes claim 1 or claim 8, nothing in the PTAB record lets you say the assertion is dead on arrival — but nothing in the record shows the patent owner has ever had to defend these claims either.

Estoppel landscape. This is the cleanest part of the picture: § 315(e)(2) estoppel is empty. No party has filed an IPR that reached final written decision, so no defendant or privy is barred from raising any ground, and no prior art has been "used up." Every invalidity theory is available to the first petitioner — § 102 anticipation, § 103 obviousness combinations, and § 112 (written description / enablement) in a PGR or district court. The single real timing constraint is § 315(b): if you have been served with a complaint alleging infringement of the '546 patent, the one-year clock to file an IPR runs from service. Note also that the patent is pre-AIA in priority (2004), so § 311(b) limits IPR to § 102/§ 103 grounds with patents and printed publications.

Pattern signals. No repeat petitioner, no defensive aggregator, and no patent-owner appeal activity exists because there is no proceeding at all. I found no evidence that Unified Patents, RPX, or an Acacia-type entity has touched this patent — the one Unified hit in my search was U.S. 7,224,678 (Stingray IP), unrelated. The absence of IPR activity is itself a signal worth weighing: 7,814,546 is a 2004-priority BBN/SPIE traceback patent in a niche (single-packet traceback + stepping-stone correlation) with a U.S. Government interest under NSA contract N66001-00-8038. Patents of that vintage that get broadly asserted against commercial defendants tend to attract IPRs. The most consistent explanation for the empty docket is that this patent has not been asserted in a campaign broad enough to motivate a petition — not that it is unassailable. I could not confirm any district court assertion of this patent through the searches I ran, and I am not asserting one does not exist; that is a gap in my data, not a finding. Verify assertion history on a live litigation docket before relying on it.

One substantive defensive lead. The '546 patent's own cited prior-art list includes two earlier BBN patents — US 6,981,158 ("Method and apparatus for tracing packets") and US 7,200,105 ("Systems and methods for point of ingress traceback of a network attack"), plus BBN technical memos on SPIE and packet-transform traceback (Snoeren et al., "Single-packet IP traceback"; Jones et al., BBN technical memo 2002). Same-assignee family art is often overlooked by a patent owner precisely because it is their own work. Those references, combined with the Wang/Reeves and Zhang/Paxson stepping-stone literature already cited on the face of the patent, are the natural starting point for an invalidity search and for a § 325(d) narrative if you later file.

Recommended next steps

• No PTAB activity exists — say so plainly rather than implying otherwise. The absence of any IPR/PGR/CBM means there is no FWD to link to and no disposition to quote, and I will not manufacture one.
• Run the § 315(b) clock now. If the patent owner (Verizon Patent and Licensing and/or RTX BBN) has served you, calendar the one-year deadline from service of the complaint. That date, not today's date, is your filing gate.
• Commission a focused prior-art search on claims 1, 8, 16, 17, and 21 anchored on (a) the BBN family references cited on the '546 face — US 6,981,158 and US 7,200,105 — and (b) the SPIE literature (Snoeren et al., Single-packet IP traceback, ACM/IEEE ToN Dec. 2002) and stepping-stone correlation literature (Zhang & Paxson, USENIX Security '00; Wang & Reeves, CCS '03). Because the PTAB docket is empty, you get first pick of the art with no estoppel and no § 325(d) baggage.
• Confirm assertion status on a live docket before strategy lock-in. My searches did not surface a district court case involving this patent; that is a search limitation, not proof of non-assertion. Check PACER/CourtListener dockets for Verizon Patent and Licensing, RTX BBN Technologies, Raytheon BBN, and BBN Technologies as plaintiffs against your industry segment.
• Note the dual assignee structure. Verizon Patent and Licensing and RTX BBN Technologies both appear as current assignees of record. Before negotiating or petitioning, resolve who holds enforcement rights and who is the correct real party in interest — it affects joinder, privity, and estoppel scope.
• Watch the clock on the patent itself. With an adjusted expiration of 2028-04-30, roughly 20 months of term remain. If you are weighing a stay-and-invalidate strategy versus a design-around or a license, the remaining term is short enough that the economics may favor delay — but short enough that a copyright-style "wait it out" is only viable if litigation timelines cooperate.

Confidence note: the "zero proceedings" conclusion is high-confidence for what the USPTO ODP returns and for what my web searches surfaced. My searches could not positively confirm or exclude a district court assertion campaign, and a very recent (post-ingest) PTAB petition would not necessarily appear in public search. Verify on PTAB E2E (https://developer.uspto.gov/ptab-api/swagger-ui or the PTAB E2E portal at https://ptab.uspto.gov) and on CourtListener (https://www.courtlistener.com) before relying on this in a filing.

I'll research the ownership chain using the primary sources. Let me run several targeted searches in parallel.

Ownership Reconstruction — US Patent 7,814,546 B1

Data-access caveat up front. The USPTO Assignment Center / Patent Assignment Search (https://assignmentcenter.uspto.gov/ ; https://assignment.uspto.gov/patent/index.html) is a JavaScript/API-driven system that did not return usable page content to my session, and my searches did not surface the reel/frame numbers or the correspondent-of-record fields for this patent. I therefore cannot provide reel/frame citations or attorney names without fabricating them, which I will not do. What follows is built from the assignment events surfaced on the patent's Google Patents "Legal Events" record (authoritative for this analysis) plus well-established corporate context. Every reel/frame and correspondent slot below is marked [not retrieved], and the chain should be re-verified directly in Assignment Center. This is a real gap, not a stylistic omission.

Inventors

• All four inventors appear as assignors on the very first recorded assignment, dated 2005-03-10 (the same day the application was filed), conveying jointly to Verizon Corporate Services Group, Inc. and BBN Technologies L.L.C. A pre-filing joint assignment of this shape is typical of a federally funded collaboration (government interest: NSA contract N66001-00-8038).
• The three Massachusetts-area residences plus the subject matter (the inventors are the authors of the SPIE/"single-packet IP traceback" literature that this patent builds on) strongly indicate the inventors were BBN-affiliated at filing, but the assignment record does not state individual employers, so I flag this as inferred, not confirmed.
• No unusual departure pattern determinable. I found no record of any inventor leaving the assignee within 12 months of filing. I have no data on inventor employment end-dates; do not read the absence as a finding.
• One minor oddity worth noting only as an observation, not a signal: Jones's residence of record (Spokane Valley, WA) is geographically far from BBN's Cambridge, MA base — consistent with a remote/relocated researcher, not an ownership red flag.

Original assignee

• Named on the issued patent (Google Patents "Original Assignee" field): Verizon Corporate Services Group Inc. and Raytheon BBN Technologies Corp. Note a literal-reading discrepancy: the original record of 2005-03-10 names BBN Technologies L.L.C., not Raytheon BBN — the Raytheon name is a later product of the 2009/2010 change-of-name chain below. I flag this as a labeling artifact in the source field, not a separate conveyance.
• Entity type / business: Verizon Corporate Services Group, Inc. is a Verizon Communications corporate-services subsidiary (Basking Ridge, NJ) — a large operating telecom. BBN Technologies (Cambridge, MA) is a defense/research contractor and the developer of the SPIE traceback system described in the specification.
• Product embodiment: The claims are not embodied in a mass-market product. SPIE was a research/defense traceback system; the claimed combination (IDS + stepping-stone detector + digest-based traceback engine) is infrastructure technology. This is a "capability" patent, not a product patent — relevant to the non-assertion analysis, since there are no competing commercial products to police.
• Current status: Both families remain operating entities. Verizon is a public operating company; BBN continues as RTX BBN Technologies, Inc., a subsidiary of RTX Corporation (formerly Raytheon Technologies). No bankruptcy or dissolution appears in the chain.

Assignment timeline

Dates below are the reassignment/recordation dates as surfaced on Google Patents; execution dates may precede them and could not be confirmed. Reel/frame and correspondent are [not retrieved] for every entry.

• 2005-03-10 (executed/recorded 2005-03-10) — Reel [not retrieved]

  • Conveyance: Assignment of assignors' interest (original inventor assignment)
  • Assignor: Jones, Christine Elaine; Castineyra, Isidro Marcos; Hain, Regina Rosales; Strayer, William Timothy
  • Assignee: Verizon Corporate Services Group, Inc. and BBN Technologies L.L.C. (joint)
  • Correspondent: [not retrieved]
  • Context: Initial joint ownership — inventors convey to the two contracting organizations of a federally funded (NSA) program.

• 2008-12-04 (recorded 2008-12-04) — Reel [not retrieved]

  • Conveyance: Security Agreement (Intellectual Property Security Agreement Supplement) — i.e., a collateral pledge, not a title transfer
  • Assignor: BBN Technologies Corp.
  • Assignee: Bank of America, N.A.
  • Correspondent: [not retrieved]
  • Context: Securitization / financing — pledge of the BBN-side IP as collateral. (Bank of America is here acting as agent, successor-by-merger to Fleet National Bank.)

• 2009-10-27 (recorded 2009-10-27) — Reel [not retrieved]

  • Conveyance: Release of Security Interest
  • Assignor: Bank of America, N.A. (successor by merger to Fleet National Bank)
  • Assignee: BBN Technologies Corp. (as successor by merger to BBNT Solutions LLC)
  • Correspondent: [not retrieved]
  • Context: Release of collateral — clearing the 2008 pledge. Timing coincides with the widely reported Raytheon acquisition of BBN Technologies (announced Sept. 2009, closed Oct. 2009); the release is consistent with satisfying the lender ahead of that acquisition, though the record does not state that linkage (inference, flagged).

• 2010-06-11 (recorded 2010-06-11) — Reel [not retrieved]

  • Conveyance: Change of Name (form-only; no change in ownership)
  • Assignor: BBN Technologies Corp.
  • Assignee: Raytheon BBN Technologies Corp.
  • Correspondent: [not retrieved]
  • Context: Internal reorg / post-acquisition name change — Raytheon's acquisition of BBN reflected as a name change on the register.

• 2014-07-28 (recorded 2014-07-28) — Reel [not retrieved]

  • Conveyance: Assignment of assignors' interest
  • Assignor: Verizon Corporate Services Group Inc.
  • Assignee: Verizon Patent and Licensing Inc.
  • Correspondent: [not retrieved]
  • Context: Internal corporate reorganization — Verizon moves its interest into its wholly-owned patent-holding subsidiary. This is intra-Verizon, not a transfer to a third-party NPE.

• 2024-08-22 (recorded 2024-08-22) — Reel [not retrieved]

  • Conveyance: Change of Name (form-only)
  • Assignor: Raytheon BBN Technologies Corp.
  • Assignee: RTX BBN Technologies, Inc.
  • Correspondent: [not retrieved]
  • Context: Internal reorg / change of name — tracks the corporate rebrand (Raytheon Technologies → RTX). No ownership change.

No recorded license, correction, bankruptcy, foreclosure, or third-party sale appears in the record.

Timeline diagram

timeline
    title Ownership of US 7814546
    2004 : Priority from provisional
    2005 : Filed and assigned to Verizon and BBN
    2008 : Security pledge to Bank of America
    2009 : Security interest released
    2010 : Patent issued
         : Name change to Raytheon BBN
    2014 : Verizon unit moves interest to VPL
    2024 : Name change to RTX BBN Technologies

(Note: the Mermaid source contains no parentheses, slashes, or commas in event text, per the parser constraint. "VPL" = Verizon Patent and Licensing Inc.)

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The only assignee that looks licensing-flavored is Verizon Patent and Licensing Inc., but the 2014-07-28 transfer came from Verizon Corporate Services Group Inc. (the same corporate family) and is a classic intra-group patent-holding reorganization, not a transfer to an unrelated single-purpose LLC. No "IP Holdings/Ventures" shell, no registered-agent address, no single-member Delaware/Texas LLC appears in the chain (all six events, 2005–2024).

2. Known asserter in the chain — not present. None of the six assignees (Verizon Corporate Services Group; BBN Technologies LLC/Corp; Bank of America; Raytheon BBN; Verizon Patent and Licensing; RTX BBN) matches Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Converso/Mosaid, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, or any Spangenberg entity. No Unified Patents / RPX high-frequency-plaintiff match surfaced.

3. Repeat correspondent across the chain — unclear / not assessable. The correspondent-of-record field was [not retrieved] for every reel. I cannot confirm or deny that a single attorney or firm handled multiple links. (Visually, the two BBN "Change of Name" filings in 2010 and 2024 plausibly share BBN/RTX legal-department correspondents, but that is speculation and I decline to treat it as a finding.)

4. Cascading transfers — not present. The chain spans 2005 → 2024 (~19 years) across six events, with multi-year gaps. There is no burst of consecutive assignee-to-assignee conveyances inside a <24-month window. The only close-spaced pair is the 2008 security pledge → 2009 release, which is a financing sequence, not a chain of title hops.

5. Pre-litigation transfer — not present. No infringement suit naming this patent was found in the prior litigation screen, so there is no suit to anchor a "within 6 months before filing" test. The 2024-08-22 event is a name change only and post-dates any conceivable assertion window.

6. Bankruptcy fire-sale — not present. No Chapter 7/11 or judicial-sale conveyance recorded. The one distress-adjacent event is the 2008-12-04 security pledge to Bank of America with a 2009-10-27 release — a financing/collateral sequence, fully resolved, not a sale of assets in insolvency.

7. Privateering — not present. No transfer of the asserted asset to an unrelated NPE. The Verizon-side interest stayed inside Verizon; the BBN-side interest stayed inside the BBN → Raytheon → RTX corporate line. Neither Verizon nor RTX appears to have offloaded this patent to an asserting entity.

8. Defensive aggregator — not present. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. It terminates at two operating/defense companies co-holding the asset.

Verdict

Defensive / non-asserting — with an explicit definitional caveat.

Every NPE signal is negative or not assessable, not positive. The chain (2005-03-10 joint inventor assignment → 2008-12-04 security pledge to Bank of America → 2009-10-27 release → 2010-06-11/2024-08-22 BBN name changes → 2014-07-28 intra-Verizon move to Verizon Patent and Licensing) consists entirely of corporate housekeeping, financing collateral, and intra-group reorganization among operating telecommunications and defense contractors, with no licensing-only shell, no known asserter, no cascading LLC hops, and no suit activity. The honest caveat: the strict definition of "Defensive / non-asserting" in this framework requires termination at a defensive aggregator, which is not the case — the asset simply sits with two operating co-owners (Verizon Patent and Licensing Inc. and RTX BBN Technologies, Inc.) and is unasserted. I select this category because it is the closest fit to a verified non-asserting operating-company asset; the alternatives ("Operating-company assertion" requires live competitor suits, and "Insufficient data" is defined as no records or only the original assignment, which understates the six-event chain I did recover) would misdescribe the record.

Two data gaps that could change signal 3 and signal 5 if closed: (a) the correspondent-of-record for each of the six reel/frame entries, and (b) exact reel/frame and execution dates. To close them, run the patent number in the USPTO Assignment Center and read the PDF coversheets directly: https://assignmentcenter.uspto.gov/ — I could not reach this system's records in this session, and I am flagging that limitation rather than papering over it.

I'll verify the patent record and dig into each cited reference, prioritizing the two BBN traceback patents, the connection-table reference, and the stepping-stone/DoS art.

Key finding already: US 6,981,158 (Sanchez/Strayer/Partridge, BBNT Solutions) is by the same inventor group and is the closest § 102 candidate. Let me now verify the remaining cited references individually.

Prior-Art Analysis — US Patent 7,814,546 B1

Scope note / literalism rule applied: Every identifier below is reproduced exactly as printed. I confined results to 7,814,546 (application 11/077,400) and did not fold in lookalike numbers that surfaced in earlier searches (7,844,915; 7,519,814; 8,526,546; US 7,827,272) — those are different documents and are excluded as prior art here except where a cited reference's grant number is legitimately noted.

Contradictions flagged before proceeding (per instructions):

1. Date conflict: the earlier sections state "Today's date is 2026-09-11" (and the Google Patents fetch timestamp 2026-09-11T06:34:04.961Z), while this task states "Current Date: April 26, 2026." This does not change the § 102 analysis (all quoted art predates 2004), but the dates are inconsistent and I am not silently picking one.
2. Status error in the litigation section: that section describes the patent as "now well expired/expiring." That is wrong. The record shows Status: Active, Adjusted expiration 2028-04-30. The patent is still in force as of either stated date. Treat the "expired" characterization as an error.

What I actually did / did not do: My retrievals returned the Google Patents record (which mirrors USPTO full-text/bibliographic data) and the uspto.report/patentimages mirrors. I did not run a direct USPTO PatentCenter or Patent Public Search query, so I cannot claim independent USPTO-database verification — I am relying on the full patent text supplied (authoritative per my operating rules) plus Google/patentimages mirrors of the same documents.

1. The patent under analysis

Because the application is pre-AIA, the critical reference date is the 2004-03-19 priority date, and the one-year § 102(b) bar runs from the US filing/priority date. Practically:

• Art published/patented on or before 2004-03-19 → § 102(a)/(b) art (and § 102(b) if more than one year before).
• US patents/published applications whose US filing date precedes 2004-03-19 but that issued/published after that date → § 102(e) art, effective as of the earlier US filing date (including a provisional filing date if the provisional provides support).

2. The ten patent citations of 7,814,546 — element-by-element § 102 review

All ten references were cited by the examiner (marked * in the record). Source: US 7,814,546 front page / citations.

2.1 Detailed treatment of the four most relevant references

(a) US 6,981,158 B1 — the single closest reference

• Full citation: US 6,981,158 B1, Method and apparatus for tracing packets, Sanchez (Mayagüez, PR); Strayer (West Newton, MA); Partridge (Lansing, MI), assignee BBNT Solutions LLC, 34 claims.
• Dates: Appl. No. 09/881,074, filed Jun. 14, 2001; claims priority to provisional 60/212,425, filed Jun. 19, 2000; issued Dec. 27, 2005.
• Art basis: § 102(e) (grant postdates the 2004-03-19 critical date; effective date = Jun. 14, 2001, arguably Jun. 19, 2000 via provisional).
• Description: An IDS detects a malicious packet → a source path isolation server (SSI) "isolates" it → SSI generates a query message (QM) containing at least a portion of the malicious packet → QM is sent to routers one hop away (source path isolation routers, SRI) → each SRI compares the query against locally stored information about packets that passed through it (hash values / bit map of hash values) → SRI replies → SSI uses replies to identify the ingress point of the packet. FIG. 4 shows the loop: receive target packet → generate QM → send to SR 1 hop away → receive response from n+1 hop away → classify as active/inactive path data → build trace of target-packet path → increment N → determine ingress point → notify IDS. (PDF), (OG record)
• Potentially anticipates: The traceback half of the independent claims — i.e., the IDS + query + router representation + reply + ingress-point determination limitations of claims 8, 16, 17 and acts 500–520 of claim 21; and directly the dependent limitations of claims 9, 10, 11, 12, 13, 18 (detection device co-located with traceback engine; target packet in the query; network component one hop away; first component is a router; reply only on observation).
• Why it still does not anticipate any claim: every one of claims 1, 8, 16, 17, 21 also requires the stepping-stone / correlated-connection-pair limitations (the second query to a second component, the table of correlated connection pairs, the previously received representative packet from the correlated incoming connection, and continuing the trace across the stepping stone). US 6,981,158 discloses none of these. Because a dependent claim carries all limitations of its parent, no dependent claim is anticipated either.
• § 103 nuance worth recording: US 6,981,158 and 7,814,546 share inventor Strayer and a common corporate origin (BBN). US 6,981,158 remains § 102(e) art for anticipation ("by another" — different inventive entity: Sanchez/Strayer/Partridge vs. Strayer/Jones/Castineyra/Hain), but its use for obviousness is vulnerable to the pre-AIA § 103(c) common-ownership disqualification, since § 102(e) is one of the enumerated categories.

(b) US 7,200,105 B1 — the digest/Bloom-filter architecture

• Full citation: US 7,200,105 B1, Systems and methods for point of ingress traceback of a network attack, Milliken; Sanchez; Snoeren, assignee BBN Technologies Corp.
• Dates: Filed Jan. 11, 2002 per the printed patent; the Google citation row lists priority 2001-01-12 (a record discrepancy I am flagging, not resolving — likely a provisional). Issued Apr. 3, 2007.
• Art basis: § 102(e) as of the earlier US filing date.
• Description: A signature tap at a node computes N k-bit packet signatures for each received packet; a multiplexer aggregates them in RAM to produce signature vectors (bits set to 1 at hash-determined addresses); a controller archives the signature vectors in a ring buffer indexed by collection interval R for the last P seconds, randomizes/merges older vectors, and ages them out. This is the DGA + time-stamped digest table + Bloom-filter aging machinery. (PDF)
• Potentially anticipates: the packet-audit limitations of claim 14 (router with a data generation agent producing packet digests, stored in time-stamped digest tables) and the "reply based on at least one packet digest produced as each of the plurality of packets is forwarded through the network" limitation of claim 17, and much of the claim 20 Bloom-filter subject matter (bit-vector indexing by multiple independent hash functions). Again: because claims 17 and 20 (and 14 via claim 13 ← claim 8) carry the stepping-stone limitations, no complete claim is anticipated.

(c) US 2004/0199791 A1 — the "connection table"

• Full citation: US 2004/0199791 A1, Connection table for intrusion detection, Poletto; Ratin; Dudfield (Mazu / Riverbed lineage; later granted as US 7,827,272 B2).
• Dates: Appl. 10/701,155, filed Nov. 3, 2003; published Oct. 7, 2004; provisionals from Nov. 4, 2002.
• Art basis: § 102(e) — publication postdates the 2004-03-19 critical date, but the Nov. 3, 2003 US filing date precedes it, so it is prior art as of that filing date (not as printed publication).
• Description: Collectors read packet metadata (source/destination addresses, transport protocol, ports, flags, length); an aggregator builds a connection table mapping each host (IP, or MAC via DHCP map) to a host object holding aggregate traffic statistics and a second-level hash map of host-pair records describing traffic in both directions between the pair, indexed by source address, destination address and time, with time-slice sub-tables. (Google Patents)
• Potentially anticipates: the table limitations of claim 2 ("IP addresses, incoming and outgoing ports, representative packets, and time last seen") and the "table of correlated connection pairs of incoming and outgoing connections" language in claims 8, 15, 16, 17 — but only for the data-structure element. Poletto's table is a traffic-statistics/anomaly table, not a stepping-stone correlation table relating an outgoing connection to a correlated incoming connection of one extended connection, and it stores no representative packet. It therefore supports at most an obviousness argument on the table element; it anticipates no claim.

(d) US 2003/0115485 A1 — hash-based tracing (same inventor lineage)

• Full citation: US 2003/0115485 A1, Hash-based systems and methods for detecting, preventing, and tracing network worms and viruses, Milliken.
• Dates: filed Dec. 14, 2001; published Jun. 19, 2003 → § 102(a)/(b) (published >1 year before the critical date).
• Description (from the record, incl. the related family language): generates hash values from packets, compares them to hashes of prior packets received within a predetermined time, flags the matching packet as potentially malicious, and "may also facilitate the tracing of the path taken by a potentially malicious packet" by receiving a message identifying the packet, generating hash values, matching them against previously received packets, and identifying the packet as one previously received.
• Potentially anticipates: the hash-digest/representation limitations underlying claims 14, 17 and the Bloom-filter concept in claim 20. It does not disclose IDS + stepping-stone table, so it anticipates nothing as a whole. Its best role is § 103 art combined with US 6,981,158 / US 7,200,105.

2.2 The remaining six patent citations (brief)

3. Non-patent literature (38 citations)

These are the references the examiner listed as "Non-Patent Citations." Grouped by function, with the ones that carry real § 102 weight first.

A. Stepping-stone detection — the art that supplies the very element omitted by every cited patent:

• Staniford-Chen, S., and Heberlein, L.T., Holding intruders accountable on the internet, Proc. IEEE Symposium on Security and Privacy '95 (May 1995), pp. 39–49 — the foundational connection-correlation/thumbprinting work. § 102(b).
• Zhang, Y., and Paxson, V., Detecting stepping stones, Proc. USENIX Security Symposium '00 (Aug. 2000), pp. 171–184 — the canonical on/off + deviation stepping-stone detector. § 102(b). This is the closest art to claim 1's "stepping stone detection device … identify correlated connection pairs."
• Yoda, K., and Etoh, H., Finding a connection chain for tracing intruders, ESORICS (Oct. 2000), pp. 191–205 — reconstructs a connection chain (i.e., the extended connection). § 102(b).
• Wang, X., Reeves, D.S., and Wu, S.F., Inter-packet delay based correlation for tracing encrypted connections through stepping stones, ESORICS (Oct. 2002), pp. 244–263. § 102(b).
• Wang, X., and Reeves, D.S., Robust correlation of encrypted attack traffic through stepping stones by manipulation of interpacket delays, ACM CCS (Oct. 2003). § 102(b).
• Donoho, D.L., et al., Multiscale stepping-stone detection: Detecting pairs of jittered interactive streams by exploiting maximum tolerable delay, RAID (Oct. 2002), pp. 14–35 — closest to the "CONCLUSION" paragraph of 7,814,546 (elapsed-time/weighted-recent-arrival analysis). § 102(b).
• Jung, H.T., et al., Caller identification system in the internet environment, USENIX Security '93; Lee, S.C., and Shields, C., Tracing the source of network attack: A technical, legal and societal problem, IEEE SMC IAW (2001); Buchholz & Shields, Providing process origin information to aid in network traceback, USENIX ATC (Jun. 2002); Carrier & Shields, A recursive session token protocol…, IEEE Infocom '02 — supporting/legal-origin work.

B. IP traceback — the art that anticipates the traceback half:

• Snoeren, A.C., Partridge, C., Sanchez, L.A., Jones, C.E., Tchakountio, F., Schwartz, B., Kent, S.T., and Strayer, W.T., Single-packet IP traceback, ACM/IEEE Trans. on Networking (Dec. 2002) — the SPIE paper. § 102(b). Most relevant to claims 14, 17, 20 and to claim 21's P/V/T/SCAR/DGA workflow.
• Sanchez, L.A., et al., Hardware support for a hash-based IP traceback, DISCEX (Jun. 2001), vol. 2, pp. 146–152. § 102(b).
• Savage, S., Wetherall, D., Karlin, A., Anderson, T., Network support for IP traceback, ACM/IEEE ToN 9(3) (Jun. 2001), pp. 226–239. § 102(b).
• Burch, H., and Cheswick, B., Tracing anonymous packets to their approximate source, USENIX LISA '00 (Dec. 2000) — router hash-logging. § 102(b).
• Belenky, A., and Ansari, N., On IP traceback, IEEE Communications Magazine 41(7) (2003), pp. 142–153 (survey). § 102(b).
• Bellovin, S.M., Leech, M., Taylor, T., ICMP traceback messages, Internet Draft (Oct. 2001) — note: an Internet-Draft is a citable publication but its public-accessibility status as a "printed publication" is a fact question.
• Mankin, A., et al., On design and evaluation of "intention-driven" ICMP traceback, ICCCN (Oct. 2001); Song, D.X., and Perrig, A., Advanced and authenticated marking schemes for IP traceback, IEEE Infocom '01 (Apr. 2001); Stone, R., CenterTrack: An IP overlay network for tracking DoS floods, USENIX Security '00 (Aug. 2000); Hazeyama, H., Oe, M., and Kadobayashi, Y., A layer-2 extension to hash-based IP traceback, IEICE Trans. on Information & Systems (Nov. 2003).

C. Bloom filters / data structures:

• Bloom, B.H., Space/time trade-offs in hash coding with allowable errors, Communications of the ACM 13(7) (Jul. 1970), pp. 422–426 — the § 102(b) reference for claim 20's Bloom filter with k hash functions (per the record, the claim literally recites that the filter "computers k distinct packet digests" — quoted literally; typographical error in the printed claim, not to be auto-corrected).
• Fan, L., Cao, P., Almeida, J., Broder, A.Z., Summary cache…, ACM/IEEE ToN 8(3) (2000), pp. 281–293 — Bloom-filter deployment.

D. Intrusion detection / network-monitoring context:

• Paxson, V., Bro: A system for detecting network intruders in real-time, USENIX Security (Jan. 1998); Snapp, S.R., et al., DIDS (distributed intrusion detection system)…, National Computer Security Conference (Oct. 1991), pp. 167–176; Schnackenberg, D., Djahandari, K., Sterne, D., Infrastructure for intrusion detection and response, DISCEX (Jan. 2000); Sager, G., Security fun with OCxmon and cflowd, Internet 2 Working Group (Nov. 1998); Howard, J.D., An analysis of security incidents on the internet 1989–1995, PhD thesis (Apr. 1997); Paxson, V., An analysis of using reflectors for distributed denial-of-service attacks, ACM CCR 31(3) (2001) (the "reflector" class in the '546 specification).

E. Protocols / addresses / miscellaneous (background for the NAT/RFC-1918 discussion in the '546 specification):

• Rekhter, Y., et al., Address allocation for private internets, RFC 1918 (Feb. 1996); Egevang, K., and Francis, P., The IP network address translator, RFC 1631 (May 1994); Ferguson, P., and Senie, D., Network ingress filtering…, RFC 2267 (Jan. 1998); Perkins, C.E., IP mobility support for IPv4, RFC 3344 (Aug. 2002); Johns, M.S., Identification Protocol, RFC 1413 (Feb. 1993); Libes, D., The Expect home page, NIST (Jun. 11, 2004); Partridge, C., et al., Using signal processing to analyze wireless data traffic, ACM WiSe (Sep. 2002); Cappe, O., et al., Long-range dependence and heavy-tail modeling for teletraffic data, IEEE Signal Processing Magazine 19(3) (2002), pp. 14–27.
• ⚠️ Jones, C.E., Tchakountio, F., Snoeren, A.C., Schwartz, B., Clements, R.C., Condell, M., Partridge, C., and Strayer, W.T., Traceback of IP packet transformations, Internal technical memo, BBN Technologies, 2002. Caveat: an internal memo is presumptively not a "printed publication" (no public accessibility), so it likely does not qualify as § 102(a)/(b) art at all — it can only matter if the applicant's own inventors rely on it, or as evidence of the state of the art for § 103 without being prior art in its own right. Do not treat it as anticipatory.

4. Bottom line on § 102

No cited reference — patent or non-patent — anticipates any claim of US 7,814,546.

The reason is structural and worth stating precisely: each independent claim (1, 8, 16, 17, 21) requires both halves of the invention in combination —

1. a packet-level traceback engine (IDS → query containing packet identification → routers that store their own representation of forwarded packets → reply → ingress point), and
2. a stepping-stone detection function that identifies correlated connection pairs, produces a table of connection pairs, and lets the traceback engine pull a previously received representative packet from the correlated incoming connection (plus its last-seen time) to continue the trace across the stepping stone.

Half (1) is squarely disclosed by US 6,981,158 B1 (with US 7,200,105 B1 for the digest/Bloom-filter specifics). Half (2) is disclosed only in the non-patent stepping-stone literature (Staniford-Chen & Heberlein 1995; Zhang & Paxson 2000; Yoda & Etoh 2000; Wang & Reeves 2002/2003; Donoho et al. 2002) and — as a traffic-statistics table only — in US 2004/0199791 A1. No single reference contains both halves, so no anticipation. Because dependent claims incorporate their parents' limitations, the dependent claims (2–7, 9–15, 18–22) are likewise not anticipated, even where (as with claims 9, 10, 11, 13, 18 vs. US 6,981,158, or claim 20 vs. Bloom 1970) their added limitations are individually old.

Most relevant prior art, ranked:

1. US 6,981,158 B1 — traceback workflow (claims 8, 16, 17, 21 acts 500–520).
2. US 7,200,105 B1 + Snoeren et al. 2002 — digest tables, DGA, Bloom-filter auditing (claims 14, 17, 20; claim 21's DGA/SCAR/STM machinery).
3. US 2004/0199791 A1 — connection table with ports/time indexing (claims 2, 8, 15).
4. Zhang & Paxson 2000 and Staniford-Chen & Heberlein 1995 — stepping-stone/correlated-connection detection (claim 1's stepping-stone element).
5. US 2003/0115485 A1 and US 2005/0132219 A1 — hash-based and flow-based single-packet traceback (claims 17, 20).
6. Supporting: Savage et al. 2001; Burch & Cheswick 2000; Belenky & Ansari 2003; Bloom 1970; Donoho et al. 2002.
7. Background only (no claim relevance): US 6,009,469; US 2002/0078202; US 2004/0098618; US 6,745,333; and the RFC/protocol citations.

Two analytic observations that matter more than the citation list:

• The 7,814,546 specification itself concedes that the stepping-stone detection module is not its contribution: "Specific details regarding the manner of detecting correlated connection pairs are not disclosed herein. It should be understood that any known systems and methods for identifying or estimating such correlated pairs may be incorporated into the system of the present invention." That concession (i) confirms the stepping-stone element is admitted prior art, (ii) shifts the entire inventive weight onto the coupling between traceback output and the connection-pair table, and (iii) raises a potential § 112(a) written-description/enablement question for the stepping-stone device as claimed, since the claim recites a structure whose operation the specification does not describe.
• Ownership/§ 103(c) caveat: the two closest patent references (US 6,981,158, US 7,200,105) are BBN-family documents, and US 6,981,158 shares inventor Strayer with the '546 patent. They remain § 102(e) art for anticipation, but a pre-AIA § 103(c) common-ownership argument would likely disqualify them for obviousness, leaving the examiner's obviousness case to rest on the non-patent stepping-stone literature (which is not commonly owned) — which is consistent with the patent having issued with all 22 claims intact.

Confidence and limits: High confidence on the bibliographic facts, dates and claim text (taken from the authoritative patent record and the patents' own front pages). Moderate confidence on the internal disclosures of US 2004/0199791 A1, US 2002/0032871 A1, US 2003/0115485 A1, US 2005/0132219 A1, US 2004/0098618 A1 and US 6,745,333 B1 — my descriptions derive from mirrored abstracts/descriptions and family citations rather than a full-text, element-by-element reading of every one of those documents, so those "potentially anticipates" judgments are preliminary. A definitive § 102 chart would require pulling each full specification and mapping limitations line-by-line. I did not locate a USPTO-hosted file-wrapper/PTAB record for this number in this session.

I'll ground this analysis in the actual prior-art references cited on the patent's face before constructing the § 103 combinations.

Obviousness Analysis — US 7,814,546 under 35 U.S.C. § 103

Scope note: This analysis is built exclusively from the references listed in the "Prior Art" / "References Cited" section of the patent's own front page (10 U.S. patent documents, 38 non-patent publications). Those references are treated as prior art of record. I have verified the substance of the key references against live sources where possible and have flagged anything I could not verify. I have not reviewed the full text of every listed reference, and the conclusions below should be treated as an examiner-style prima facie case, not a final validity opinion.

I. Analytical framework

The controlling inquiry is Graham v. John Deere as refined by KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007). The four Graham factors:

1. Scope and content of the prior art;
2. Differences between the prior art and the claims;
3. Level of ordinary skill in the pertinent art;
4. Secondary considerations (with a required nexus).

Level of ordinary skill (PHOSITA): A person with an M.S. in computer science/electrical engineering, or a B.S. with 3–5 years of experience in network security and Internet protocol design, working on IP traceback and intrusion detection. Notably, the reference set itself is populated with the same DARPA/NSA-funded research community (Snoeren, Partridge, Sanchez, Strayer, Jones, Milliken, Paxson, Staniford-Chen), which means the PHOSITA here is presumed familiar with all of these references — they were the state of the art in the same sub-field.

Field of the art: Both "IP traceback" and "stepping-stone detection" are, per the patent's own background, sub-parts of a single problem. The specification states verbatim:

"The attribution problem can be divided into two parts: (1) finding the source of a flow of attack packets, called the IP Traceback Problem, and (2) discovering which sources are acting to launder the attack, called the Stepping Stone Problem."

That sentence is the single most damaging admission in the document. It establishes that the two claimed sub-systems solve two recognized halves of one known problem, in one field, at one time.

II. The prior art of record

III. Claim-construction points that collapse the gap

Three constructions matter, and each is dictated by the specification's own lexicon:

1. "Traceback engine" — the spec equates this to SPIE: "a Source Path Isolation Engine (SPIE) (400 in FIG. 4) is used as an IP traceback system." So "traceback engine" reads directly onto Snoeren's STM/SCAR/DGA system and onto BBN '158's "source-path isolation server."

2. "Stepping stone detection device" — the specification expressly disclaims any particular detection method:

   "Specific details regarding the manner of detecting correlated connection pairs are not disclosed herein. It should be understood that any known systems and methods for identifying or estimating such correlated pairs may be incorporated into the system of the present invention."

   This is a written-description-style admission that the claimed stepping-stone detector is the known art, incorporated wholesale. It substantially forecloses any argument that the detector itself supplies inventive weight.

3. "Table of connection pairs" — claim 2 defines it as "IP addresses, incoming and outgoing ports, representative packets, and time last seen." That is a conventional connection-record schema (Poletto) plus two extra columns. The extra columns are the only arguably novel data, and their motivation is discussed in § VI.

IV. The primary combination

Combination A (attacks claims 1, 8, 16, 17, 21, 22)

Snoeren et al. (SPIE) + Zhang & Paxson (stepping stones) + US 6,981,158 (BBN) + Poletto '791 (connection table)

Claim 21 is the cleanest case. Nearly every element is recited in SPIE's own terminology:

Claim 17 falls to the same combination with the digest limitation supplied by Snoeren (Bloom-filter digest tables) and/or US 7,200,105 ("signature tap computes signatures… archived… provided to an agent for determining a point of ingress").

Claims 1 and 8 are met by Snoeren + Zhang/Paxson + BBN '158, with the "representative packet" limitation addressed below in § VI.

Claim 16 is the same subject matter in Beauregard form and adds nothing patentable. In re Beauregard, 53 F.3d 1583 (Fed. Cir. 1995).

Combination B (attacks the dependent claims)

V. Why the pieces fit without modification (the KSR rationales)

Under MPEP § 2143, any of the following rationales supports the combination. Here, five apply simultaneously.

(A) Combination of prior-art elements according to known methods, yielding predictable results

Both subsystems are network-security instrumentation that (i) observe traffic at routers, (ii) maintain bounded-state records keyed by connection/packet, and (iii) answer queries about historical traffic. Combining them requires only that one query interface accept another's output. The expected result — a trace that does not terminate at the first stepping stone — is exactly the result obtained. No unexpected property is asserted in the specification; the stated benefit is simply that the trace continues.

(B) Design incentive articulated in the references themselves

Zhang & Paxson expressly contemplate retrospective, cross-site use: "when an attacked site contacts the site from which they were immediately attacked, that site could then consult its traffic logs and run an off-line stepping stone detection algorithm to determine from where the attacker came into their own site." This is a direct teaching to couple stepping-stone detection with a traceback workflow that hands off between regions — precisely the architecture of claim 21 (SCAR-to-SCAR hand-off) and claim 8 (traceback engine → stepping-stone component → traceback engine).

(C) The patent's own statement of the motivation

The specification states:

"Integrating stepping stone detection with IP traceback addresses these two problems."

and identifies the two problems as (1) source-address invalidity via NAT, and (2) the need for a global host→data-collection-point mapping to stitch connection pairs. This is a textbook design incentive and, more importantly, a statement of the problem to be solved that a PHOSITA would have recognized. Under KSR, "the problem is not the invention."

(D) Applying a known technique to a known device ready for improvement

SPIE is the known device; it is expressly "ready for improvement" because its own paper concedes that traceback terminates at the boundary of the SPIE system and cannot resolve what is behind the identified ingress host. Stepping-stone detection is the known technique for answering exactly that question. Applying it is the KSR "use of a known technique to improve a similar device in the same way."

(E) Same field, same problem, same community

All references are in network attack attribution. The inventors of the patent (Strayer, Jones) are co-authors of the Snoeren SPIE paper, and Strayer is an inventor on US 6,981,158. The PHOSITA is not asked to bridge distant fields — this is a single, tightly-knit art.

(F) No teaching away

Nothing in Snoeren, Zhang & Paxson, Staniford-Chen, or Poletto teaches away from integration. Zhang & Paxson's observation that legitimate stepping stones are common is a policy/false-positive-ratio concern, not a technical incompatibility; MPEP § 2145 requires a teaching away to be a "clear and unambiguous" discouragement of the claimed solution, and a warning about false positives does not dissuade a PHOSITA from coupling a detector to a tracer.

VI. The single genuinely integrative limitation, and why it is still obvious

The one element that is not literally in any single reference is claim 1's requirement that the traceback engine determine, "using the established connection pair table, a previously received representative packet, the representative packet being from an incoming connection correlated with the connection including the malicious packet," and use that packet to continue the trace. Claim 2 adds "time last seen."

Two independent, mutually reinforcing motivations make this obvious:

1. SPIE's interface requirement. Snoeren/BBN '158 both require a specific packet instance as the trace input — the query message contains "at least a portion of the malicious packet," and results are time-bounded. Anyone integrating a table lookup with SPIE must therefore store a packet exemplar in the table. That is a functional necessity, not a design choice.

2. Digest-table aging. Snoeren's Bloom filters are paged and overwritten on an interval; BBN '200,105 literally randomly zeros out signature vectors older than P seconds. The specification itself states the motivation:

   "Since the SPIE system is sensitive about the age of the packets it traces—the older the packet, the less likely evidence of the packet's path is still kept in the Bloom filters… the packet that gets installed into the connection pair table should be the last packet seen… along with the time that packet was seen."

   Selecting "the most recent packet" and recording its timestamp is the paradigm of an obvious design choice / predictable variation (MPEP § 2144.04), driven by an explicit constraint in the primary reference. There is no alternative that a PHOSITA would have regarded as equally viable — the newest packet is the only one with a chance of surviving in the digest tables.

VII. Anticipation exposure on the dependent claims

For completeness, several dependent claims are not merely obvious but arguably anticipated by single references:

• Claim 22 (victim V expressed as the last-hop router, not the end host): recited as a design constraint in Snoeren's SPIE paper. This is close to a per se § 102 issue if the reference's disclosure is read as enabling the practice.
• Claim 20 (Bloom filter computing k distinct digests using independent uniform hash functions): Snoeren (and Bloom 1970) disclose this in haec verba.
• Claims 14 and 18–19: DGA timestamped digest tables and "reply only if observed" are Snoeren's digest-membership mechanics.

These matter because the Federal Circuit treats additional dependent-claim limitations as insufficient to confer patentability where the independent claim is obvious. In re Kao, 639 F.3d 1057 (Fed. Cir. 2011).

VIII. Rebuttal analysis — what the applicant would argue, and why it is weak

Written-description/support problems are a further vulnerability. Claim 21 recites SPIE component names (STM, SCAR, DGA, "enhanced router") that appear in the specification only in relation to the incorporated SPIE reference, and the specification never describes how the connection-pair table is built ("Specific details… are not disclosed herein"). That creates an enablement/support question under § 112(a) independent of § 103.

IX. Secondary considerations

No evidence of secondary considerations appears in the record reviewed. Two caveats:

• The earlier litigation search (consistent with my review) found no IPR/PGR or district court litigation involving 7,814,546; therefore there is no litigation-induced record of commercial success, copying, or long-felt need with a nexus to the claims.
• The patent is co-owned by Verizon Patent and Licensing Inc. and RTX BBN Technologies Corp., with Government rights under NSA contract N66001-00-8038. Government-funded infrastructure R&D of this type rarely generates the market-success evidence needed to rebut a strong prima facie case.

Even if such evidence existed, copying of a specific integrated architecture would be weak where the prior-art references were authored in substantial part by the same research group and share an inventor with US 6,981,158 — the nexus would be to the group's pre-existing SPIE work, not to the claimed increment.

X. Conclusion and confidence

Bottom line. Claims 1, 8, 16, 17, and 21 are, in my assessment, highly likely obvious over the combination of:

• Primary: Snoeren et al., "Single-Packet IP Traceback" (IEEE/ACM ToN, Dec. 2002) — supplying the traceback engine, STM/SCAR/DGA architecture, digest tables, Bloom filters, IDS interface, hop-by-hop query/reply, and last-hop-router victim;
• Secondary: Zhang & Paxson, "Detecting Stepping Stones" (USENIX Security 2000) (or Staniford-Chen & Heberlein 1995; Yoda & Etoh 2000) — supplying stepping-stone detection and the correlated connection-pair relation;
• Tertiary: US 6,981,158 B1 (BBN) and US 7,200,105 B1 (BBN) — supplying the IDS-triggered query/reply ingress-determination workflow and packet-signature archiving; and Poletto US 2004/0199791 A1 — supplying the connection-table structure.

The only element approaching novelty — storing a representative packet and time last seen for the correlated incoming connection and feeding it into the next trace iteration — is an obvious design choice dictated by SPIE's packet-specific query interface and its aging digest tables, as the patent's own specification concedes.

Confidence: High as to the claim-element mapping against Snoeren and Zhang & Paxson (both verified against live sources at the URLs below). Moderate as to BBN '158 / '200,105 element-level mapping, since I reviewed abstracts and claim 1 rather than full specifications. Lower as to the commercial/litigation context, because no litigation record was located.

Sources consulted:

• https://patents.google.com/patent/US7814546/en
• https://patentimages.storage.googleapis.com/c1/2a/9c/6c22f7cd07e250/US7814546.pdf
• U.S. Patent 7,814,546 full text and claims (22 claims)
• https://acm-prod.literatumonline.com/doi/10.1109/TNET.2002.[804827](/patent/804827) (Snoeren, Single-Packet IP Traceback)
• https://www.icir.org/vern/papers/stepping/index.html (Zhang & Paxson, Detecting Stepping Stones)
• https://static.usenix.org/events/sec2000/full_papers/zhangstepping/zhangstepping.pdf
• https://webapp1.dlib.indiana.edu/virtual_disk_library/index.cgi/[5628977](/patent/5628977)/FID979/OG/html/1301-4/us06981158-20051227.html (US 6,981,158 B1)
• https://patents.google.com/patent/US7200105 (US 7,200,105 B1)
• https://insight.rpxcorp.com/patent/[US7200105B1](/patent/US7200105B1)

One explicit contradiction to flag between this and the previously generated sections: the litigation summary described the patent as "now well expired/expiring," which conflicts with the patent's own recorded adjusted expiration of 2028-04-30 (20-year term from the 2005-03-10 filing would be 2025-03-10, extended by 1,147 days of PTA per the printed notice). For an obviousness analysis the distinction is immaterial, but the earlier characterization was inaccurate.