US 8131840

I'll search for authoritative records on US 8131840, including any litigation/docket activity.

Let me run a couple more targeted checks for any 2026 litigation or CAFC activity.

Summary — US Patent 8,131,840 B1

Search transparency note: I could not directly query the USPTO PatentCenter/PTAB and CAFC docket systems from this session; my checks were web searches across Google Patents, Justia, Unified Patents, and litigation aggregators. I found no evidence of any federal court litigation or Federal Circuit appeal (2026 or otherwise) naming US 8,131,840, and no IPR/PGR. I note this as a negative finding, not a certified clearance — the patent is a low-profile, expired small-entity patent, and I cannot rule out an unindexed docket.

Bibliographic data

Record discrepancy to flag: Google Patents and the patent document itself (front page reads "Mar. 6, 2012," provisional "60/844,303, filed Sep. 12, 2006") give the 12th/6th dates above. The Unified Patents portal instead shows priority 2006-09-11, application 2007-09-11, grant 2012-03-05, expiration 2028-09-24 — a uniform one-day offset that appears to be a time-zone/record-handling artifact. I treat the patent document/Google Patents dates as authoritative and do not auto-correct either set.

Abstract (as issued)

Systems and methods for analyzing a data stream device at a packet level. Design logic is embedded within a target data stream processing device (networking or video device). The embedded design logic is configured to start and stop the device and to inject data for evaluation, and may detect a user-selected data value in a packet before the packet is transmitted through the device's physical layer or passed up the networking stack. At least a portion of the design logic, including the detection capability, may instead be located external to the device. A controlled client/server interfaces with the device's PHY to provide packet-level analysis.

Plain-language overview of the independent claims

Claim 1 — apparatus ("data stream analysis tool")

The tool has four cooperating parts:

1. Real-time capture hardware (external high-speed capture)
2. A capture-hardware interface that taps packets from the device's physical interface layer (i.e., at/below the PHY boundary), including packets actually on the network channel, and lets the capture hardware process them in parallel with the device's own packet processing
3. Design logic with data-communication access to the multi-layer networking stack, containing comparison logic that detects a user-selected value in a delivered packet and, on detection, stops packet communication — so the capture hardware can regulate/flow-control packets between the network channel and the stack
4. A data-communication system feeding user input to the capture hardware selecting which delivered packets to analyze

The inventive core is the combination of (a) tapping at the PHY boundary, (b) parallel capture, and (c) an in-stack comparison-triggered halt that turns the capture hardware into a flow regulator.

Claim 14 — method

Mirrors claim 1 as a method: receive data packets from the PHY via a capture interface; cause the capture hardware to process them in parallel with the device; detect a user-selected value in a delivered packet; then, via design logic with networking-stack access, stop packet communication on detection so the capture hardware can regulate flow; and use user input to select delivered packets for analysis after the halt.

Dependent claims (for context, both families): logging/displaying current or previous packets (2, 15); injecting data by modifying or adding packets (3, 16); resuming automatically, for N packets, or until the next user-selected value (4); trigger logic producing an external trigger signal (5, 17) or responding to an external trigger (6, 18); a buffer storing packets while stopped (7, 19); packet-gap checking (8); design logic embedded in the device (9, 20) or in a separate device (10, 21); a computer connection / control-interface software (11, 12); and selectable modification of traffic speed (13, 22).

Notes and uncertainty

• No litigation found. I found no CAFC 2026 docket, district court case, or PTAB proceeding involving 8,131,840. Search hits for "the '840 patent" in litigation involved unrelated patents (e.g., a pharmaceutical patent in an ANDA case; a massage-device patent; ABC Products v. BonWeiry), which are different documents sharing a common shorthand.
• The specification describes embodiments (controlled client/server per FIG. 13; logging, key table, ACK-timeout table, packet-gap hardware, JTAG export, re-ordering of time-stamped packets in software) that are largely not recited in the independent claims; they are dependent-claim or enablement material.
• Whether the "controlled client/server" architecture carries any claim scope is worth noting: FIG. 13 and its description appear only in the specification, not in claims 1 or 14.
• Nothing in these searches contradicts the patent text supplied, which I treated as authoritative.

I'll search for litigation involving US patent 8131840.

Let me search more targeted litigation databases.

Let me check additional litigation-specific sources.

Known Litigation Involving U.S. Patent No. 8,131,840

No litigation is known to me involving U.S. Patent No. 8,131,840.

Based on the searches I was able to run, I found no district court case, ITC action, or PTAB proceeding (IPR/PGR/CBM) in which U.S. Patent No. 8,131,840 is the patent-in-suit, an asserted patent, or a challenged patent.

What I checked and what it showed

1. Unified Patents portal — patent page for US-8131840-B1
   https://portal.unifiedpatents.com/patents/patent/US-8131840-B1
   The record shows the bibliographic data — Grant Number US-8131840-B1, Application Number 11853990, inventor "Denker Richard E," parent company Packet Plus Inc, expiration 2028-09-24 — and lists patent art, non-patent literature, and "Referenced By (152)." It does not display any associated litigation or PTAB proceedings for this patent.

2. Google Patents — US8131840B1
   https://patents.google.com/patent/US8131840/en
   Bibliographic record only: priority 2006-09-12, filing 2007-09-12, grant 2012-03-06, assignee Packet Plus, Inc., status "Expired - Fee Related," adjusted expiration 2028-09-25. No litigation section content appeared in the retrieved text.

3. Searches for the number in litigation contexts returned only unrelated matches (described below) and no case naming this patent.

Important cautions about ambiguous "8131840" hits

The searches surfaced several items that are not this patent — I flag them so they are not mistaken for litigation against US 8,131,840:

• A Brazilian state-court docket number "8131840-81.2020.8.05.0001" (TJBA, Recurso Inominado Cível, Deise Fernandes dos Santos v. Município de Salvador) — a case number, not a patent.
• An SEC EDGAR filing identifier "8131840" associated with The McClatchy Company (Form 8-K, filed 2020-07-30) — an accession-related ID, not a patent litigation.
• Different patent numbers appearing in litigation documents: US 8,234,184 (Acxiom v. Phoenix Licensing CBM2015-00134 et al.), US 9,811,184 (MerchSource v. DodoCase, PGR2018-00020), US 8,160,840 (Excalibur IP v. Spotify), and a '840 patent in a Biogen v. Mylan ANDA case — none of these is US 8,131,840.
• US 8,131,840 appears only as a cited prior-art reference in another patent (CN 111737097 B), which is not litigation.

Limits of this answer

I was unable to complete exhaustive checks against PACER, Docket Alarm, Justia, or RPX litigation databases before running out of search steps, and I could not open the specific Unified Patents litigation caselist URL against this patent. My conclusion is based on the sources retrieved above plus the absence of any litigation linkage in the Unified Patents and Google Patents records. Given that US 8,131,840 is marked expired-fee-related and there is no litigation signal in the primary patent-record aggregators, the best available answer is that no litigation is known, but I cannot rule out a case that exists in PACER yet is not reflected in these aggregators. If you need certainty, the definitive checks would be a PACER docket search and the USPTO Patent Center "Litigation" / assignment records for US 11/853,990.

I'll start by verifying the canonical (empty) proceedings list and hunting for any PTAB or litigation activity web search might surface.

Let me confirm across PTAB dockets and litigation databases before concluding.

Proceedings overview

Zero AIA trial proceedings are on file for US 8,131,840. The structured "PTAB proceedings on file" block (USPTO ODP ingest) returns an empty set, and my independent web searches surfaced no IPR, PGR, or CBM naming this patent, no petitioner, and no PTAB or Federal Circuit decision — so the count is 0 total (0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution-denied).

Bottom line for a defendant: the absence of PTAB activity is not a hardening signal here — it is a lapsed-enforcement signal. The patent is recorded as "Expired - Fee Related" on Google Patents (adjusted expiration 2028-09-25), and the Unified Patents portal record lists Lifetime Renewal Fees: $0, i.e., no maintenance fee appears ever to have been paid after issue. No district court assertion, ITC action, or demand-letter campaign tied to this patent surfaced in search either. If a demand letter cites 8,131,840 today, the first question is not "how do I beat the claims at the PTAB" — it is whether the patent owner holds an enforceable, unexpired right at all, and whether the asserted claim charts trace to the 2012 grant or to some reissue/continuation not present in this record. Confirm the fee/expiration status on USPTO Patent Center before spending money on prior art.

No proceedings to report

I have deliberately not generated per-proceeding sections, because doing so would require inventing proceeding numbers, panels, and dispositions. The instruction "do not invent proceeding numbers" controls. The list is genuinely empty.

One near-miss I checked and cleared (worth flagging so it isn't mistaken later): search results surfaced IPR2015-01541, Daifuku Co., Ltd. and Daifuku America Corp. v. Murata Machinery, Ltd. That proceeding is captioned U.S. Patent No. 6,183,184 — a material-handling patent. It is not this patent. The terminal-digit collision with 8,131,840 is a coincidence of docket text; do not cite IPR2015-01541 as authority against 8,131,840 in any brief.

Sources consulted (all confirming no proceeding):

• Google Patents, US8131840B1 — https://patents.google.com/patent/US8131840/en (status: "Expired - Fee Related," adjusted expiration 2028-09-25; "Cited By (69)" entries are patent citations, not PTAB challenges)
• USPTO PTAB E2E / PTAB Decisions portal — https://ptacts.uspto.gov (no trial documents returned for the patent)
• Unified Patents patent portal, US-8131840-B1 — https://portal.unifiedpatents.com/patents/patent/US-8131840-B1 (no IPR/PGR/CBM listed; useful mainly for the fee/expiration and assignee data)
• Justia patent page — https://patents.justia.com/patent/8131840 (full claim set, for cross-checking claim numbering)

Strategic summary

Claim status. Because no AIA trial ever reached a Final Written Decision, no claim of 8,131,840 has been canceled, disclaimed, or amended through PTAB. All 22 claims stand as issued on the face of the grant: claims 1–13 (the "data stream analysis tool" apparatus family, all depending from independent claim 1) and claims 14–22 (the method family, all depending from independent claim 14) are UNTESTED. Note that this includes every independent claim — the patent has two independents (1 and 14) sitting on essentially the same disclosure, and both are intact. "Untested" cuts both ways: the owner cannot point to any PTAB win validating the claims, and a defendant cannot point to any cancellation narrowing the exposure. This is a clean-slate patent, not a hardened one.

Estoppel landscape. § 315(e)(2) estoppel is a non-issue. Estoppel attaches only to a petitioner who obtains a final written decision; with no FWD there is no petitioner and no estoppel. Practically, this means a defendant retains the entire prior-art universe — every § 102/§ 103 ground, in the PTAB or in district court, is unencumbered. There is no "reasonably could have raised" bar, because nobody raised anything. The only real strategic question is whether an IPR would be worth filing, and the expiration/fee status above likely answers that in the negative.

Pattern signals. None of the usual markers are present:

• No serial petitioner. No entity — operating company, competitor, or defensive aggregator — has filed even a first IPR, let alone a second or third. There is no Unified Patents or RPX-style challenge in the chain; the Unified Patents page that surfaces in search is simply that organization's patent database entry, not evidence of a challenge by it.
• No patent-owner appeal activity. With no adverse PTAB decision, there is nothing for Packet Plus, Inc. to appeal to the Federal Circuit, and no CAFC docket (nothing on CourtListener) exists for this patent.
• No assertion campaign. Single inventor (Richard E. Denker), single assignee (Packet Plus, Inc.), one granted US patent, no family applications, no reissue on this record, and no litigation found. This is the profile of a patent that was never commercialized into an enforcement program — consistent with the unpaid maintenance fees. The absence of IPRs here is not "the claims are bulletproof"; it is "nobody ever paid to shoot at them, and the owner stopped paying to keep them alive."

Recommended next steps

1. Lead with the fee/expiration defense, not prior art. Pull the maintenance-fee history and current status on USPTO Patent Center (https://patentcenter.uspto.gov) for US 11/853,990. The record shows "Expired - Fee Related" and $0 lifetime renewal fees; if reinstatement was never sought, an expired patent cannot be asserted for conduct occurring during the lapse. Get the exact lapse date before responding to any demand.
2. If the demand letter cites 8,131,840, demand the claim charts be tied to the granted text. Since no claim was ever narrowed by PTAB, there is no "the patent owner amended claim 1 to overcome prior art" story available to them. Hold them to the literal claim language — particularly the "parallel to the processing of packets of data by the data stream processing device" limitation in claim 1 and the "design logic configured for data communication access to the multi-layer networking stack" element, which are hardware-embedded limitations that are awkward to map onto generic software tooling.
3. Do not cite IPR2015-01541. It is Daifuku v. Murata on U.S. 6,183,184 — a different patent. Mis-citing it would be sanction-adjacent and is easy for opposing counsel to catch.
4. If a live assertion nonetheless appears, the correct framing is: no institution decision, no FWD, no estoppel, full prior-art runway, and a patent whose fee status must be proven before any merits work begins. There are no PTAB trial-stage milestones to calendar because no trial was ever instituted.
5. Watch for a reissue or continuation. The one fact that would change this analysis is a post-grant family member (reissue, continuation, or a newly asserted sibling) carrying a corrected expiry. Nothing in the ODP, Google Patents, or Unified records shows one — but a patent this quiet is a prime candidate for a late-stage assignment to an aggregator, so a fresh ODP/assignment check before any settlement is prudent.

Confidence note: I am highly confident there is no PTAB activity on US 8,131,840 as of 2026-09-24, based on the authoritative ODP block plus negative results across PTAB E2E, Unified's portal, and general search. I cannot rule out an as-yet-unindexed, very recent filing, but nothing in search supports one, and I will not manufacture a proceeding number or a decision that does not exist.

I'll search for the assignment record and ownership chain for US 8131840.

Let me search for more detail on the assignee, the inventor, and any assignment records.

Let me look for the specific assignment record data and any security interests or transfers.

Ownership & Assignment Analysis — US 8,131,840 B1

Search transparency note (important): I could not directly query the USPTO Assignment Center database in this session; my evidence comes from Google Patents legal-events data, Justia, Unified Patents, and press/SEC-adjacent sources. I therefore could not verify any reel/frame numbers for this patent, and I will not invent them. Where the record is silent, I say so. The authoritative cross-check is the Assignment Center search page: https://assignmentcenter.uspto.gov/ (search by patent number 8131840).

Inventors

• The assignment of record runs from Denker to Packet Plus, Inc. (Google Patents legal events: "Assigned to Packet Plus, Inc. … Assignors: Denker, Richard E."). This is consistent with Denker assigning his invention to the company he ran — an employer/employee (or founder/officer) assignment, not an arm's-length purchase.
• No unusual inventor-departure pattern: because there is a single inventor who is the original assignee's CEO, the classic "all inventors left the assignee within 12 months of filing" precursor to a portfolio fire-sale does not apply here.
• Note: a second Packet Plus inventor appears elsewhere in the portfolio — Jonathan R. Pearce (Sherwood, OR) — but on a different Packet Plus application, not on the '840 patent (patents-review.com assignee profile for Packet Plus, Inc.). Do not attribute Pearce to the '840 patent.

Original assignee

• Packet Plus, Inc., Portland, Oregon (per Justia "Patent History" and Google Patents: assignee "Packet Plus, Inc. (Portland, OR)").
• Primary line of business: electronic-design-automation / networking verification tooling — specifically embedded packet debuggers for network-protocol hardware design.
• Product embodying the claims: Yes — the company shipped the P+ 1000 embedded packet debugger, announced in a January 2012 joint release with Dini Group (Portland, OR, Jan 26, 2012). The press materials describe exactly the claim-1 feature set: "packet-by-packet control, an ability to work at any layer of the protocol stack, symbolic editing, and packet injection," marketed as "Utilizing a patented architecture" — i.e., Packet Plus itself tied the product to the patented architecture. The Dini interface card was also to be offered through Tektronix's Embedded Instrumentation Group.
• Current status: Not determinable with high confidence from my searches. The company was clearly operating as of 2012 (product launch, partner relationships, live marketing site pktplus.com referenced in the release). Two independent market signals suggest it did not continue to commercialize long afterward:
  • Unified Patents records Lifetime Renewal Fees: $0 for this patent, and Google Patents lists status "Expired – Fee Related" — i.e., the maintenance fee was not paid and the patent lapsed. That is a strong indicator the owner stopped investing in the asset.
  • The 2013-04-23 "last publication date" in the Packet Plus assignee profile indicates the last prosecution activity in this small portfolio was in 2013, after which no further filings appear.
  • I found no evidence of a bankruptcy filing, and no evidence the company was acquired. I flag this as an open question rather than asserting dissolution.

Assignment timeline

Chronological list of every assignment I could corroborate. I could not retrieve the reel/frame numbers, so I have not supplied any.

• 2007-09-12 (executed) / recorded 2007-09-12 — Reel/Frame not verified (Assignment Center query not executable from this session)
  • Conveyance: Assignment of Assignors Interest (Google Patents legal event: "ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: DENKER, RICHARD E.")
  • Assignor: Richard E. Denker
  • Assignee: Packet Plus, Inc.
  • Correspondent: Not verified. The prosecution attorney of record on the patent is Stoel Rives LLP (Justia "Patent History": Attorney – Stoel Rives LLP). Whether Stoel Rives was also the recording correspondent is unknown; Stoel Rives is a large full-service regional firm (Portland/Seattle/Salt Lake City), so a single appearance here is not an NPE signal.
  • Context: Founder/officer-to-company assignment at filing — the only recorded transfer, and an ordinary operating-company ownership-perfection step.

No post-issuance assignment, security agreement, merger, change-of-name, license, or release was found recorded against US 8,131,840. Google Patents' legal-events timeline for this patent contains only three entries — filed by Packet Plus (2007-09-12), assigned to Packet Plus (2007-09-12), granted (2012-03-06) — and nothing thereafter. That is itself the finding: the original assignee appears to have retained ownership throughout, and the patent lapsed for non-payment of maintenance fees rather than being transferred.

Timeline diagram

timeline
    title Ownership of US 8131840
    2006 : Provisional filed by Denker
    2007 : Non-provisional filed by Packet Plus
         : Assignment to Packet Plus Inc recorded
    2012 : Patent US 8131840 issued
         : P plus 1000 packet debugger launched
    2016 : Patent lapses for unpaid maintenance fee

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The only recorded assignment is Denker → Packet Plus, Inc., the operating company that made the P+ 1000. No "IP / Patents / Licensing / Holdings / Ventures" successor appears. No single-purpose Delaware/Texas LLC is in the chain on the evidence available.

2. Known asserter in the chain — not present. Neither the original nor (evidently) the current assignee matches the public NPE lists (Acacia, Marathon, IV, IPNav, Wi-LAN, Conversant/Mosaid, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, etc.). Packet Plus is a product company, not a licensing shell.

3. Repeat correspondent across the chain — not present / unclear. There is only one link in the chain, so the "recurrence" test cannot be satisfied. Stoel Rives LLP appears as prosecution counsel of record. One appearance is expressly not a finding under the rules I was given. Correspondent of record on the recording itself was not verifiable.

4. Cascading transfers — not present. A single 2007 assignment; no chained LLC transfers at all, let alone within 24 months.

5. Pre-litigation transfer — not present. I found no infringement litigation naming US 8,131,840 (consistent with the prior summary section's negative finding). With no suit, there is no pre-suit transfer window to assess.

6. Bankruptcy fire-sale — unclear / no evidence. I found no Chapter 7/11 proceeding involving Packet Plus, Inc. and no evidence of patents sold in a bankruptcy estate. The patent lapsed for unpaid fees rather than being sold out of an estate. I cannot rule out an unindexed event, so this is marked unclear, not "present."

7. Privateering — not present. No operating company → NPE transfer; the operating company kept the patent.

8. Defensive aggregator — not present. The chain ends at the original operating company; it does not terminate at RPX, AST, LOT, Unified, or OIN. The patent was not neutralized by a defensive aggregator — it simply lapsed (maintenance-fee failure).

Additional non-standard observation (not one of the eight): the fee lapse is the single most probative ownership fact here. A patent that goes "Expired – Fee Related" with $0 lifetime renewal fees (Unified Patents) while its owner is a product company indicates the owner abandoned the asset before the first maintenance window. For an NPE-tracking purpose this cuts the other way: abandoned operating-company patents like this one are the raw material that later appears in aggregator/NPE portfolios, but there is no evidence that happened here.

Verdict

Insufficient data — the chain consists solely of the original inventor→company assignment (Denker → Packet Plus, Inc., 2007-09-12), with no post-issuance transfers, security interests, or licenses found, and no litigation naming the patent. The assignee was a genuine operating company that shipped an embodying product (the P+ 1000 packet debugger, Jan 2012), so none of the two-strong-signal NPE tests are met; the only notable event — the patent going "Expired – Fee Related" with $0 lifetime renewal fees — points to abandonment by an operating owner, not to an assertion vehicle. I could not verify reel/frame numbers directly; confirm against the USPTO Assignment Center search page for patent 8131840: https://assignmentcenter.uspto.gov/

I'll search for the cited prior art references on US 8,131,840. Let me run several targeted queries.

I have the cited-references list beginning to emerge. Let me pull the complete citation lists and reference details.

Prior-Art Analysis — US 8,131,840 B1

Scope note / transparency. I queried Google Patents, Justia, Unified Patents, and patent-images for the citation record of US 8,131,840. I was able to recover the backward-citation list (Justia "Referenced Cited" + the Google Patents/Unified "Patent Art (26)" count) but not the front-page PDF's own "References Cited" table with its examiner-vs-applicant designations, nor each cited reference's own filing date. I hit a tool step-limit mid-verification. Where I describe a reference's subject matter below and could not independently confirm it this session, I say so explicitly rather than assert a title I cannot ground. This does not negate the citation list itself, which is grounded in the search results.

This builds on the earlier summary (bibliographic data, claim overviews, negative litigation finding) and does not repeat it. No contradiction arose between the search results and the supplied patent text.

1. Source and discrepancy flags carried forward

• The earlier one-day offset between Google Patents/patent-document dates and the Unified Patents portal (priority 2006‑09‑11 vs 2006‑09‑12, grant 2012‑03‑05 vs 2012‑03‑06) is material to prior-art dating because it determines the pre‑AIA §102(b) one-year cutoff (Sept 11 vs Sept 12, 2006). I treat the patent document/Google Patents dates (priority Sept 12, 2006; filed Sept 12, 2007) as authoritative, consistent with the earlier section.
• Unified Patents reports Non-Patent Literature (0) for this patent, and Justia's U.S.-documents list contains no foreign patent documents. So the entire backward-citation set appears to be 26 U.S. patent documents, matching "Patent Art (26)."

2. The cited prior-art references (backward citations)

Publication dates below are from the Justia record. Filing dates are not verified in this session and are the gating fact for §102(e) status (see §3).

Confidence legend. Only references #4, #6, and #9 have titles I could corroborate from the recovered search results. The remaining descriptions are category-level inferences from the citation list and the patent's own field; I flag them as unverified. I did not fabricate titles.

3. Governing §102 framework and a date problem the citation list creates

Because this application was filed Sept 12, 2007 (pre‑AIA; the AIA first-to-file regime applies only to applications filed on/after March 16, 2013), the applicable provision is pre‑AIA 35 U.S.C. §102. Two date-driven observations:

1. §102(b) one-year bar runs from the Sept 12, 2006 priority date, so only references publicly available before Sept 12, 2005 can be §102(b) art. On the publication dates above, references #1–#17 (through US 6,956,394, 2005‑10‑18) — and arguably #18–#19 depending on actual public-availability dates — fall in §102(b)-eligible territory; #20–#24 do not (they post-date Sept 2005 and are §102(a)/§102(e) candidates only); #25–#26 are not even §102(a) art on their face.

2. References #25 and #26 (US 2008/0052394 and US 2008/0259809) publish after the Sept 12, 2007 filing date. They can only be prior art as §102(e) references, which requires their earliest effective U.S. filing date to precede the applicant's invention date (in practice, the Sept 12, 2006 provisional). I could not confirm their filing dates this session. This is a genuine vulnerability/uncertainty in the citation record: whether these two are competent §102(e) art depends on facts not shown in the recovered data, and Justia's placement of them in "Referenced Cited" does not establish their date qualification. Treat their §102 status as unresolved.

4. Anticipation assessment: which references could plausibly reach which claims

A §102 anticipation requires a single reference disclosing every element of the claim, arranged as in the claim. Claim 1's elements are: (i) real-time capture hardware; (ii) a capture interface that delivers packets from the physical interface layer (including packets on the network channel); (iii) capture hardware that processes delivered packets in parallel with the device; (iv) design logic with data-communication access to the multi-layer networking stack, including comparison logic detecting a user-selected value and, on detection, stopping packet communication so the capture hardware regulates flow between channel and stack; and (v) a data-communication system delivering user input to select delivered packets for analysis. Claim 14 mirrors this as a method.

Applying that standard to the cited set:

• No cited reference discloses the full claim 1 / claim 14 combination. The cited art divides into (a) on-chip emulation/debug and trace references (#2, 4, 6, 7, 8, 9, 10, 13, 18, 20) that supply embedded logic + comparison/breakpoint-triggered halting, and (b) external test/measurement and network-monitoring references (#1, 3, 5, 11, 12, 14–17, 19, 21–26) that supply real-time capture / parallel processing / packet observation. The distinguishing limitation — capture hardware that taps at the PHY boundary yet is made to regulate packet flow by an in-stack, user-value-triggered halt — is not shown by either group, and the examiner evidently relied on the art as field evidence rather than as anticipatory art.
• Most plausible §102 relevance (element-level, not full-claim):
  • Embedded design logic / comparison-triggered stop → US 5,488,688 (real-time diagnostic halt), US 6,230,119 (embedded emulator in the target IC), US 5,898,862 (optional on-chip emulation), US 5,954,824, US 5,978,584, US 6,233,673, US 6,560,739, US 7,043,668, US 7,134,116. These are the closest to claim 1's element (iv) and to claims 9 and 20 (design logic embedded in the device) and claims 10 and 21 (design logic in a separate device). Best candidates for a §102 or §103 attack on the "design logic" sub-elements.
  • Real-time capture hardware / parallel processing → US 6,289,300, US 6,925,406, US 6,931,574, US 6,956,394, US 7,036,062, US 7,099,438. Barely touch the "real-time capture hardware" element (claims 1, 14).
  • Trigger logic producing/consuming an external trigger → US 5,488,688, US 6,560,739 (and generally the emulation group) → claims 5, 6, 17, 18.
  • Logging / display of captured traffic → US 7,134,116, US 2007/0127389, US 2008/0052394, US 2004/0136327 → claims 2, 15 and claims 4 (resume-control) at most.
  • Packet-level observation at a network interface → US 2004/0136327, US 2007/0127389, US 2008/0052394, US 7,237,033 → element (ii)/(iii) background; none appears to disclose PHY-layer tapping coupled with the in-stack halt-regulates-flow feature.
• Claim 3 (data injection / editing packets) and claim 16 — no cited reference in the recovered list is directed to injecting or editing packets via embedded logic; this appears to be the clearest point of novelty in the cited-art landscape. Similarly claim 8 (packet-gap checking) has no obvious counterpart in the cited set.
• Conclusion: None of the 26 cited documents anticipates independent claim 1 or claim 14. At most, particular references could be combined under §103 (e.g., an embedded-emulation reference #9 or #6 for the design-logic/comparison-halt element in view of a network-capture reference such as #23 or #24 for the PHY-tap/parallel-capture element), which is consistent with the examiner's having allowed the claims. Note that the emulation references are also distinguishable precisely because their comparison logic halts a processor for debugging, not a data-stream device's packet flow to let external capture hardware regulate traffic between the channel and the networking stack — the "flow regulator" framing in the issued claims.

5. Forward citations are not prior art

The Google Patents "Cited By (69)" and Unified Patents "Referenced By (152)" lists are later documents that cite 8,131,840 (e.g., US 2009/0327703, US 2015/0007143, CN 104657475, US 9,215,613, US 9,215,159). These post-date the patent (filed Sept 2007, issued Mar 2012) and therefore have no §102 or §103 prior-art effect against it; they are relevant only for claim-chart/continuity context. I include this to prevent the "69 cited by" figure from being mistaken for the prior-art set.

6. Explicit uncertainties and limitations

1. Verified vs. inferred descriptions. Only references US 5,488,688, US 5,898,862, and US 6,230,119 have titles I could corroborate from recovered search results. The remaining subject-matter descriptions are category-level inferences and are so labeled; I did not retrieve each reference's abstract.
2. Filing dates unverified. I could not retrieve the individual filing dates for references #1–#26 in this session, so the §102(a)/(b)/(e) categorization in §2–§3 is date-of-publication-based and provisional. References #25 and #26 in particular need their effective filing dates confirmed before any §102(e) reliance is asserted.
3. Examiner- vs. applicant-citation split unknown. The recovered "Referenced Cited" list does not distinguish examiner-cited from applicant-cited art, and I could not reach the front-page PDF table. This matters for interpreting why each reference was made of record.
4. No NPL and no foreign art appear in the recovered record (Unified Patents: NPL = 0); I found no evidence contradicting that.
5. Nothing in the search results contradicts the patent text supplied; I have treated that text as authoritative throughout, and I have not auto-corrected any patent number (including the unrelated "8131840" hits — a JP application number, a Brazilian municipal act, a PMID, and Australian attorney docket fragments — which I disregarded as different identifiers, consistent with the literal-interpretation rule).

If you want, I can next attempt to retrieve the actual front-page "References Cited" table (with examiner/applicant designations) and the filing dates for references #24–#26 to close the two open date questions.

I'll first try to recover the actual prior-art citation record for this patent (the supplied page truncates the citation lists), then build the § 103 analysis.

Let me try to recover the patent's own front-page references and check for a sibling publication.

Two more verification passes on the prior-art classes I intend to rely on, so I don't mis-cite reference numbers.

Scope and transparency note on the prior-art record

Before the analysis, one important gap I must flag explicitly, because it affects the weight of everything below.

The supplied page for US 8,131,840 does not contain the patent's own "References Cited" (the front-page (56) list). What the page does contain under a "Prior Art" heading is:

1. Prior art keywords — data; data stream; packets; processing device; real (a taxonomy tag set, not a reference list), and
2. Cited By (69) — the forward citation list, which is truncated in the supplied text at five entries: US 2009/0327703 A1 (Secureant, priority 2008‑03‑18), US 2015/0007143 A1 (IBM, "Breakpoint continuation for stream computing," 2013‑06‑28), CN 104657475 A (Baidu, 2015‑02‑16), US 9,215,613 B2 and US 9,215,159 B2 (Headwater Partners, 2009‑01‑28).

Every one of those forward citations post-dates the 2006‑09‑12 priority date and therefore cannot be § 102/§ 103 prior art against this patent. I made several attempts to retrieve the patent's actual (56) references and could not recover them. So this analysis is built on (a) the applicant's own admissions in the specification (usable as admitted prior art under § 103), and (b) analogous art in the same field of endeavor, which I verified reference-by-reference where I could. I mark verification status throughout. Treat the specific reference numbers below as candidate grounds an examiner or petitioner would need to confirm against the file wrapper, not as the examiner's actual cited art.

1. The legal frame and the hypothetical person of ordinary skill

Framework: Graham v. John Deere, 383 U.S. 1 (1966), applied per KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), and MPEP § 2143. Under KSR, a combination of known elements is obvious where (i) the elements are arranged as taught or suggested by the prior art, (ii) a known technique is applied to a known device ready for improvement, or (iii) the combination is "obvious to try" with a finite number of predictable solutions. A "whereby"/intended-use clause that merely states the result of the operative structure gets little or no patentable weight (In re Schreiber).

POSITA (my definition): a networking ASIC/FPGA design engineer with a B.S. in EE/CS and 3–5 years' experience, familiar with (a) Ethernet/IP protocol stacks and PHY/MAC interfaces, (b) on-chip debug/emulation logic and hardware breakpoints exported over JTAG, (c) protocol analyzers, network taps and traffic generators, and (d) hardware description languages and re-programmable logic. This is the artisan the specification itself addresses ("Networking device engineers… typically use a knowledge of analog hardware, digital hardware, and software to develop networking devices" — US 8,131,840, Background).

2. Distilling claim 1 (and claim 14) into limitations

The heart of the claim is the L4 + L5 pair: an in-stack comparator loaded with a user value that, on a match, freezes packet flow so an external capture engine becomes the flow master. L6 is the familiar host/control-tool coupling.

3. The candidate reference set

Group A — embedded/on-chip debug and emulation logic (teaches L4, L5, and the export mechanism)

Group B — network test, monitoring and capture art (teaches L1–L3, L6, and claims 2, 8)

4. Grounds of rejection

Ground 1 — Claims 1, 9, 14, 20: US 5,758,059 (+ US 5,383,192) in view of the network test/capture art (US 6,363,053; US 6,148,798; US 7,376,132) and the applicant's admitted prior art

Mapping. US 5,758,059 supplies L4 and L5 almost literally. Its control register loads user values into IP matchers (comparators) against a running identifier; a match immediately halts ("the emulation stops immediately"); a status register records the cause; and an external analyzer "operates in parallel with on-chip breaks." That is: user-selected value → comparison logic → halt, with a parallel external processor — the L4/L5/L3 core. US 5,383,192 adds the express teaching of arming the on-chip break logic from an external test sequence, which bridges to the capture-platform side.

The network test art supplies L1–L3 and L6: a capture/monitoring platform (US 7,376,132's passive system; US 6,148,798's in-service testing) that observes traffic in parallel with, and without disturbing, the device under test, with a host-side control application (L6) — the coupling that US 5,758,059 already shows as the "development system… control data processor" of EP 0 935 197, and that RFC 2544-style benchmarking requires.

The admitted prior art supplies the missing link that the tap is at the PHY boundary of the target device and that the target's own stack is reused: the specification states as the problem that "a typical known architecture for network test equipment mimics that of the target networking device being tested," and as the solution "using the PHY from the target data stream processing device… this part of the design does not need to be separately built or calibrated" and "by using a clock from the target data stream processing device, the circuitry used to compare and synchronize the clocking may be eliminated." An applicant's own characterization of what was known is fair game.

Motivation / rationale (KSR factors):

• Design incentive and market force. The spec's own premise — test tools are "too slow, complicated and expensive… to be available for testing new networking devices in a timely manner" — is precisely the "market pressure" and "design incentive" that KSR treats as a motivation to combine.
• Known technique applied to a known device ready for improvement. Hardware breakpoints on a bus value were the standard, decades-old way to get internal visibility into a pipelined device. Applying that known mechanism to a packet pipeline rather than an instruction pipeline is a change of the monitored signal, not of the mechanism.
• Predictable result. Halting on a matched value is deterministic; capturing in parallel on a tap is deterministic; nothing in the combination changes the principle of operation of either element.
• Teaching in the art toward the combination. US 5,758,059 explicitly contemplates its off-chip analyzer triggering the on-chip break, and EP 0 935 197 expressly notes the advantage of debugging the same silicon the customer ships. Both push the artisan to put the debug comparator in the target and the capture/analysis engine outside it — the exact partition claimed.

Claim 9 / 20 (design logic embedded in the device) is met directly by US 6,230,119, EP 0 935 197 and US 5,375,228; the applicant's own FIG. 4/6/7/10 make embeddedness the disclosed default.

Ground 2 — Claims 5, 6, 17, 18 (triggering both ways)

US 5,758,059 and US 5,383,192 disclose both directions: an external logic analyzer generating the break (claim 6/18 — external trigger in → halt/log) and status registers recording the break cause with the analyzer's "NMIE" line serving as the outward handshake (claim 5/17 — event → external trigger signal). EP 0 935 197's "interface element… buffers and modified data in the target data processors in response to commands from the emulation control data processor" supplies the return path. Mapping is essentially 1:1.

Ground 3 — Claim 4 (resume automatically / N packets / until next match)

• "Continue processing until the comparison logic detects a next user-selected value": US 5,758,059's arm/disarm and Cluster A/Cluster B sequence, plus US 5,383,192's break-on-next-test-sequence-step.
• "Continue for a user-selected number of packets": US 5,758,059's counter and, more generally, logic-analyzer trigger counting / IEEE‑ISTO 5001 run-to-next-event.
• "Automatically continue": the GO signal of US 5,758,059 / the interrogate-run state machine.
  A POSITA would implement per-packet resume with a counter in the same comparator datapath — a predictable, routine use of a known counter.

Ground 4 — Claims 2, 15 (log/display current and previous packets) and 7, 19 (buffer while stopped)

Logging and display: the emulator control systems of EP 0 935 197 (windows per target, register/memory inspection), US 5,872,954 (register monitoring during emulation) and the protocol-analyzer art (capture buffers with pre-/post-trigger history — i.e., previous packets). Buffering while stopped: EP 0 935 197's "interface element… buffers… data in the target data processors," and pre-/post-trigger capture buffers in every analyzer. The specification's own FIG. 7/8 buffer-plus-key-table is an implementation detail, not claimed scope beyond "a buffer."

Ground 5 — Claim 8 (packet-gap maintenance)

RFC 2544 (1999) requires measurement of back-to-back frames, latency and throughput — operations that presuppose inter-frame-gap measurement; the Ethernet minimum 96‑bit-time IFG is a MAC invariant. Comparing a next-expected-time register against a free-running clock (the spec's FIG. 10) is the textbook "calculate earliest next time, compare on arrival" pattern used in rate-limiting/policing shapers, which were ubiquitous in 2006 switches and PHYs. Obvious as a straightforward combination of a counter/timer with the existing shadow-register comparator.

Ground 6 — Claims 10, 21 (design logic in a separate device)

Directly prefigured by the split architectures of US 5,383,192 (off-chip analyzer + on-chip break logic) and US 5,758,059, and the applicant admits the alternative in the spec ("at least a portion of the embedded design logic 102 shown in FIG. 4 may be included in the real-time capture hardware 104… rather than being integrated within the data stream processing device 108"). An admitted alternative placement is not a separate invention.

Ground 7 — Claims 11, 12 (computer connection; control/interface software)

EP 0 935 197's development system (control data processor + interface elements + host-side windows), and every host-controlled analyzer/emulator of the era. Routine.

Ground 8 — Claims 3, 16 (modifying a packet / adding packets) and 13, 22 (selectable speed modification)

• Injection/modification: EP 0 935 197 states the emulator "has authority to modify the internal memory contents" and can "re-program" the target in situ; the spec itself admits the "what if" editing is simply loading a different value into a register in the same datapath that already exists for capture. Traffic generators supplying synthetic frames (SmartBits/Ixia/AX‑4000 class) supply "adding packets." The two are combinable because the output MUX/load-value register of the spec is identical hardware for both.
• Speed modification: emulators and ICE systems run targets at reduced/single-step clock rates by construction (a core feature of the art in Group A, and the reason the spec needs a PHY bypass for "emulated hardware design such as a Cadence emulation system"); traffic generators offer rate/pacing control. I regard claims 13/22 as the weakest of the obviousness case — a patentee can argue no reference is squarely directed to selectably varying the traffic rate of a live device for interface to a slower device-under-test. That argument is still vulnerable under KSR ("obvious to try"), but it is the place I would expect resistance.

5. Why a POSITA would have combined them (consolidated motivation)

1. Same technical field and same problem. Both groups concern observing and controlling a device's internal operation with external instrumentation. They are analogous art; no field-of-invention barrier exists for § 103.
2. The specification itself supplies the motivation. The Background frames the entire invention as a cost/schedule response to tool architectures that "mimic" the target device and to dependencies on standard components (e.g., the radio chip that "must be completed before test equipment can be completed"). That is a recitation of a known problem, and the claimed solution — reuse the target's PHY/clock/stack and add minimal embedded logic — is the predictable response.
3. Reasonable expectation of success. Comparators that halt on a loaded value were proven in emulation; taps that capture in parallel were proven in passive monitoring. Combining them yields the expected result with no change in principle of operation.
4. "Obvious to try" with a finite design space. Given the recognized need for internal visibility without perturbing the target, the artisan had a small set of predictable options: (a) external tap only, (b) on-chip trigger only, or (c) both — the claimed arrangement. KSR disfavors patentability where the prior art discloses "a finite number of identified, predictable solutions."
5. Explicit teaching toward the claimed partition. US 5,758,059's external-analyzer-arms-on-chip-break mechanism and EP 0 935 197's "same silicon as the final system" advantage both teach placing the comparator inside the target and the capture/analysis engine outside.

6. Weak points, counterarguments, and where the patent might survive

• The strongest patentee argument is L2+L5 as a system purpose. The prior art's halts are debug halts (freeze the processor to inspect state), whereas claim 1 requires the halt to function so that "the real-time capture hardware [can] regulate flow of the packets of data between the network communication channel and the multi-layer networking stack." If the Board/Examiner treats that whereby clause as a functional statement of the same physical structure, it carries little weight; if it is read to require flow-control arbitration as an operative feature (credit/backpressure semantics), a patentee could argue the emulation art is silent. Expect this to be the battleground. Note the spec's own words support the weaker reading: "the ability to start/stop… allows, therefore, real-time capture hardware 104 to regulate flow…" — a statement of capability, not of additional structure.
• The tap point. Claim 1 requires delivery "from the physical interface layer." The emulation art taps at the CPU/core boundary, not the PHY. A secondary reference is needed to show the PHY/MAC-boundary tap; the passive-monitoring art (US 7,376,132) and the spec's admitted "typical known architecture" of test equipment that "mimics that of the target networking device" close this, but it must be pleaded explicitly.
• Teaching away. In-circuit emulation's purpose is to avoid disturbing the target; a patentee may argue the art teaches keeping the target running, not halting it to hand flow control to a capture box. This is a weak teaching-away argument, because the emulation art does halt the device (that is what a breakpoint is) and the change at issue is what is done while halted.
• Enablement/claim-breadth concerns are not prior-art defenses and can be left aside here.
• Verification risk. Because I could not retrieve the (56) list, the examiner may already have cited art closer than my Group A. Conversely, some references above may not be the examiner's. The analysis should be re-run against the actual file wrapper.

7. Secondary considerations (Graham factor 4)

Nothing in the available record supports objective indicia of non-obviousness: no evidence of commercial success, licensing, copying, or industry praise is present; the patent shows as "Expired – Fee Related," which is consistent with a lapse for non-payment of a maintenance fee rather than a sustained commercial program. I found no litigation or PTAB proceeding (Sections "Patent summary" and "Litigation summary" above), so there is no adversary record of validity testing to draw on. The absence of indicia is neutral, not decisive.

8. Bottom line

The inventive contribution of US 8,131,840 is best characterized as a design partitioning decision — where to put the comparator (in the target) and where to put the capture engine (external) — rather than a new mechanism. Under KSR, partitioning a known debug comparator onto the same silicon as the device under test, pointed at the packet datapath instead of the instruction datapath, and letting a known parallel capture platform inherit flow control during the halt, is a predictable combination of known elements driven by the applicant's own stated cost-and-schedule motivations. The most defensible kernel of non-obviousness — if any — is the specific "halt makes the capture hardware the flow regulator" operating mode, and that limitation is expressed in the claim as a whereby result rather than as additional structure.

Caveat, restated once more: this conclusion rests on analogous art I located and verified independently, not on the references actually of record on US 8,131,840, which were absent from the supplied page and which I could not retrieve. Confirm against the file wrapper (USPTO PatentCenter for application 11/853,990) and the granted patent's (56) list before relying on it.