US 8850571

I'll search for this specific patent number and its current litigation status.

Let me run additional targeted searches.

Let me search specifically for the claims of this patent.

Search Report: US 8,850,571 B2

Scope note on the searches. I ran searches targeting the exact string 8850571 / 8,850,571 against patent databases, litigation aggregators, and general web sources. I found no CAFC 2026 docket entries for this patent. I also found that searches for "‘571 patent" in 2025–2026 litigation press releases return Alpha Modus Corp.'s ‘571 patent portfolio (retail marketing/advertising technology) — a different patent unrelated to US 8,850,571. Those results should not be conflated with the patent you asked about. On a strict literal reading, no litigation hit in my results names US Patent No. 8,850,571.

Bibliographic Data

The following is drawn from the full patent text supplied to me (authoritative per your instructions) and corroborated by Google Patents and Justia:

Assignment chain of record (per Google Patents): FireEye, Inc. → Mandiant, Inc. (change of name, 2023-02-02) → FireEye Security Holdings US LLC → Musarubra US LLC (merger, 2024-08-13) → Magenta Security Intermediate Holdings LLC and Magenta Security Holdings LLC (2024-08-15). UBS AG, Stamford Branch holds first- and second-lien security interests recorded in 2021 and 2024.

Related/priority-linked family matters named in the record: the application is related to U.S. App. Ser. No. 11/409,355 ("Heuristic Based Capture with Replay to Virtual Machine," filed 2006-04-20), and nominally linked to US 8,997,219, US 9,118,715, US 8,990,939, US 9,438,622, and US 9,954,890 through shared priority.

Abstract (verbatim from the patent)

"A method for detecting malicious network content comprises inspecting one or more packets of network content, identifying a suspicious characteristic of the network content, determining a score related to a probability that the network content includes malicious network content based on at least the suspicious characteristic, identifying the network content as suspicious if the score satisfies a threshold value, executing a virtual machine to process the suspicious network content, and analyzing a response of the virtual machine to detect malicious network content."

Plain-Language Overview of the Claims

⚠️ Explicit uncertainty flag. The full text supplied to me is truncated mid-specification (at step 425 of FIG. 4) and does not include a claims section, and my search calls did not retrieve verbatim claim text before I exhausted my search budget. I therefore cannot state the independent claims verbatim, nor can I confirm how many independent claims exist or whether the set includes system and/or computer-readable-medium claims in addition to a method claim. What follows is a plain-language reconstruction based on the patent's own Summary section, which in this document tracks the claimed subject matter nearly word-for-word, plus the FIG. 3 workflow. Treat it as an accurate description of the disclosed invention, not as a verified claim chart.

Probable independent method claim (mirrors the Summary section): A method for detecting malicious network content that involves:

1. Inspecting one or more packets of network content (e.g., via a heuristic module at a network tap, mirroring traffic without blocking it);
2. Identifying a suspicious characteristic ("feature") of that content — e.g., a keyword, an eval(unescape(...)) JavaScript sequence, a tiny iframe, or suspicious filename extension;
3. Determining a score reflecting the probability the content is malicious, based on that characteristic (the specification uses an approximate Bayesian analysis expressed as log₂(P_m|f) = log₂(P_f|m)/log₂(P_f|n), Eq. 1, optionally via a pre-computed lookup table);
4. Flagging the content as suspicious if the score meets an analysis threshold (which may be dynamically adjusted based on system load and virtual-machine availability);
5. Executing a virtual machine to replay/process the suspicious content in a simulated client environment; and
6. Analyzing the virtual machine's response (crashes, unusual memory accesses, spawned processes, unexpected network transmissions) to confirm actual malicious content.

Conceptual technical scope (as disclosed): The disclosed system is an out-of-band, tap-based architecture comprising a heuristic module 130, heuristics database 135, scheduler 140, virtual machine pool 145, and analysis environment 150 (with replayer 205, virtual switch 210, and virtual machine 215). The stated point of novelty relative to the proxy-based prior art is that content is not held and blocked pending analysis; heuristics triage traffic cheaply, and only flagged content is escalated to a computationally expensive virtual machine — reducing false positives and avoiding a network bottleneck. The specification expressly distinguishes the invention from Provos et al. ("All your iFRAMEs Point to Us," 2008), which relied on a crawler-built web repository and could not inspect and select pages in transit.

System / CRM claims: Based on the specification's "above-described modules … comprised of instructions stored on storage media" language, a system or computer-readable-medium claim is plausible, but I cannot confirm this without the claim text.

Matters I Could Not Verify

1. Verbatim claims — not available in the authoritative text provided (truncated) and not retrieved.
2. Any CAFC 2026 appeal or 2026 district-court assertion of this specific patent — no results found; absence of evidence is not evidence of absence, and my search was not exhaustive of PACER/Docket Navigator.
3. Post-issuance proceedings (e.g., IPR/PGR or reexam) — no authoritative results surfaced in my searches; I decline to speculate.
4. Priority date discrepancy — the authoritative Google Patents record states 2008-11-03, and a secondary aggregator (Unified Patents) lists 2008-11-02 for this grant number. Per your literal-interpretation rule, I report both and do not reconcile them. The filing date of App. Ser. No. 12/263,971 is 2008-11-03.
5. Expiration — the record shows an adjusted expiration of 2029-08-09 (i.e., beyond the nominal 20-year date of 2028-11-03), which implies patent term adjustment; this is a record entry, not a legal conclusion, and is contingent on maintenance-fee payment.

Sources: Google Patents, https://patents.google.com/patent/US8850571/en; Justia Patents, https://patents.justia.com/patent/8850571; USPTO.report, https://uspto.report/patent/grant/8850571.

I'll research litigation involving US Patent 8,850,571. Let me search multiple sources.

The initial results returned unrelated "885" patents (Sonos, Exigent, Taction). Let me narrow to the specific patent number and owner.

Let me search more targeted sources and check for IPR/PTAB proceedings as well.

Findings: Litigation Involving U.S. Patent No. 8,850,571

Bottom line: I was unable to identify any district court litigation, CAFC appeal, ITC action, or PTAB post-grant proceeding specifically involving U.S. Patent No. 8,850,571. If litigation exists, it did not surface in the sources and search queries I was able to run before hitting my research limits.

I want to be explicit rather than manufacture a case list. Here is what I did and did not find.

What the patent is

U.S. Patent No. 8,850,571 ("Systems and methods for detecting malicious network content"), filed 2008‑11‑03, granted 2014‑09‑30, naming Stuart Gresley Staniford and Ashar Aziz as inventors. Original assignee FireEye, Inc.; the public record shows a chain of reassignments leading to Magenta Security Holdings LLC (via Mandiant, Musarubra US LLC, and FireEye Security Holdings US LLC). It is part of FireEye's foundational "heuristic based capture with replay to virtual machine" family (see related applications 11/409,355; 11/152,286; 11/096,287; 11/151,812 cited on the face of the patent).

What I searched and what came back

1. General queries for "8850571" / "8,850,571" + litigation — returned only unrelated patents that happen to be numbered '885 somewhere: the Sonos '885 patent (Google v. Sonos), Exigent's '885 patent, and Taction's '885 patent. None are U.S. 8,850,571. Per your instruction, I am not treating these as matches.
2. Unified Patents litigation portal — no case list entry for 8,850,571 surfaced.
3. Finjan v. FireEye / Finjan Holdings press and SEC materials — these relate to Finjan's patents (e.g., 6,804,780; 8,079,086; 7,975,305; 8,225,408; 7,058,822; 7,647,633; 6,154,844) asserted against FireEye (e.g., N.D. Cal. 4:13‑cv‑03133‑SBA). That is the reverse posture from this patent and does not concern U.S. 8,850,571.
4. FireEye SEC/risk-factor filings — returned generic third‑party infringement risk language, with no identification of 8,850,571.

Important caveats

• This is a negative finding, not a certification that no litigation exists. The Unified Patents portal, Docket Alarm, Justia, CourtListener, and PACER are the authorities that would confirm this, and I was unable to complete a full sweep of them (I hit my tool-call limit mid-investigation). You should re-run the specific-patent search directly on those databases.
• A patent can appear in litigation as (a) an asserted patent, or (b) merely cited in an invalidity contention, IPR petition, or damages/exhibit list. My searches would not reliably surface the latter.
• No case number, jurisdiction, filing date, or outcome can be responsibly reported for 8,850,571 on the record I retrieved, so I am not supplying any. Inventing those fields would violate the accuracy requirement.

Recommendation for a definitive answer

Search these directly by the exact number:

• Unified Patents Portal → Litigation → Case List (search "8850571")
• PTAB / Unified PTAB Portal for any IPR/PGR listing 8,850,571 as the challenged patent
• PACER / CourtListener / Docket Alarm for full-text of complaints mentioning "8,850,571" (note: an encoded "8850571" can also be mistaken for the many other '885 patents, so verify the assignee is FireEye/Magenta)

If you'd like, I can attempt these specific database queries next and report back with any confirmed hits and their case metadata.

I'll verify the "no PTAB activity" default with targeted searches before writing this up.

I hit my tool-call limit mid-sweep, but the searches I completed (plus the canonical ODP block in this prompt) all point the same direction. Here is the analysis.

Proceedings overview

Total AIA trial proceedings on U.S. Patent No. 8,850,571 as of the most recent USPTO Open Data Portal ingest: zero — no IPR, no PGR, no CBM, active or otherwise. Breakdown by status is therefore N/A (0 active / 0 invalidated / 0 sustained / 0 settled / 0 institution-denied). Defensive posture: the patent is un-attrited, not hardened. Every claim of 8850571 is UNTESTED before the PTAB. That cuts both ways for a defendant — there is no canceled claim to lean on, but equally no PTAB precedent, no petitioner estoppel, and no FWD reasoning to borrow. Any invalidity fight would be a first-impression, from-scratch petition.

I want to be explicit that this is a negative finding, not a certification. I searched by patent number, by assignee (FireEye / Magenta / Mandiant / Musarubra), and by technology ("malicious network content," "replay to virtual machine," "virtual machine detection"), and separately looked for Unified Patents activity in this family. Nothing surfaced specifically for 8850571. My sweep was not exhaustive (see caveats), so treat the zero as high-confidence-but-verify rather than certain.

No proceedings to report

Because the canonical list from the USPTO ODP contains no AIA trials for 8850571, there are no per-proceeding entries (petitioner, panel, grounds, institution decision, FWD, settlement, or appeal) to populate. I am not going to fabricate a proceeding number, panel, or disposition to fill the template. If a proceeding does exist outside the ODP ingest, it will have a real number on the PTAB E2E system and I would need to read it there.

What I checked and did not find (so you can rule these out)

• Unrelated "885" hits. Searches for "8850571" returned other patents numbered with '885 (Sonos, Exigent, Taction) and, in PTAB contexts, U.S. 8,252,571 (Reactive Surfaces v. Toyota/Univ. of Minnesota sovereign-immunity cases) — a different patent in a different technology. None is 8850571.
• FireEye's other patents that were IPR'd. FireEye's patent family did attract PTAB challenges, but on different patents. The clearest example surfaced: Finjan obtained a Final Written Decision invalidating a majority of claims in FireEye's '533 and '499 patents (see Patexia, "Finjan Invalidates FireEye Claims through IPR," 2015-07-14, https://patexia.com/feed/finjan-invalidates-fireeye-claims-through-ipr-20150714). Those are separate FireEye patents, not 8850571. Do not let a search engine conflate them.
• Unified Patents. Unified's defensive-aggregator activity in adjacent cyber-security patents (e.g., Finjan's 8,079,086; Lionra's 9,264,441) is real, but I found no Unified petition against 8850571, and Unified's public write-ups name other patents.

Strategic summary

Claim status: all UNTESTED. No claim of 8850571 has been canceled, confirmed, or even substantively construed by the PTAB, because no AIA trial has been instituted. Contrast this with the broader FireEye/Magenta portfolio, where sibling patents were hit (the '533/'499 FWDs noted above). The 8850571 claims therefore stand exactly as granted in 2014 — granted claims are presumed valid under 35 U.S.C. § 282, and a defendant starts from that presumption.

Estoppel landscape: empty, in both directions. Because there is no Final Written Decision on any claim, § 315(e)(2) estoppel does not attach — no petitioner or privy is barred from raising any ground. Practically, that means if you file, you get a clean slate: § 102/§ 103 on patents and printed publications, and IPR-eligible grounds are all available. It also means the patent owner faces no adverse PTAB judgment and no § 42.73(d)(3) estoppel. The one tactical nuance: if 8850571 shares a priority chain with patents that were adjudicated (it claims priority through the 11/409,355 "Heuristic Based Capture with Replay to Virtual Machine" line, and is related to 8997219 / 9118715 / 8990939), prior PTAB constructions of shared terms — and any § 315(b) one-year bar running from service of a complaint asserting 8850571 — are the things to nail down before filing. I could not complete the § 315(b) date analysis here.

Pattern signals. No repeat petitioner, no serial IPRs, no PTAB appeal history, and no defensive-aggregator footprint tied to this specific patent. That is the signature of a patent that has not been a standalone assertion target — consistent with the litigation summary already generated for this patent, which likewise found no identified district-court assertion. A patent that is asserted but never IPR'd is unusual; a patent that is neither asserted nor IPR'd is more likely sitting in the portfolio, licensed, or used as background art leverage rather than as a courtroom weapon.

Recommended next steps

• No PTAB activity exists — say so plainly to your client. The absence is itself a signal, but do not oversell it: "never challenged" is not the same as "unchallengeable." Well-asserted patents eventually attract IPRs; this one simply has not been asserted hard enough yet.
• Before filing anything, verify the negatives on the authorities, because my sweep was incomplete:
  • PTAB E2E / PTAB Center at https://ptacts.uspto.gov/ptacts/ — search the exact number "8850571" under Trials.
  • Unified Patents Portal → PTAB/Litigation Case List — search "8850571."
  • CourtListener / Docket Alarm / PACER for any complaint, IPR petition, or invalidity contention citing 8850571 (verify the assignee is FireEye/Magenta/Mandiant — encoded "8850571" collides with the other '885 patents).
  • Federal Circuit docket — no appeal exists absent an FWD, so a null here confirms the picture.
• If you intend to file an IPR, confirm (a) the § 315(b) one-year deadline from any served complaint asserting 8850571, (b) whether a parallel district-court stay posture is available, and (c) the priority/§ 102 art date, since 8850571's effective filing date (2008-11-03) and its continuation-in-part lineage will heavily constrain which art qualifies. Given no prior IPR, there is no ready-made claim-construction record to inherit — budget for a full Phillips construction from scratch.
• If you are defending against a demand letter and it cites 8850571, note there is no cancelled claim to point to. Your levers are § 101/§ 112 and § 102/§ 103 art, invalidity contentions built fresh, and the patent's own file history — not a PTAB FWD.

Caveats (stated plainly): I did not complete a full pass of PTAB E2E, CourtListener, and PACER before hitting my tool limit. A recently filed petition or a recently issued FWD that the ODP has not yet indexed would not appear in my results. No proceeding number, panel, or disposition can be responsibly reported on the record I retrieved, so I am reporting none rather than inventing any.

I'll research the assignment records for this patent, focusing on reel/frame numbers and correspondents of record.

I found a key assignment record. Let me dig deeper into the specific assignment records for this patent number.

Assignment Record Reconstruction — US 8,850,571

Method and completeness caveat (read first). I reconstructed this chain from (a) the Google Patents legal-events record supplied as authoritative in the source text, and (b) targeted searches of USPTO Assignment Center / Plainsite mirrors of the same records. I retrieved a reel/frame number for only one link in the chain (the 2024 Magenta leg, below). For the remaining links the USPTO Assignment Center metadata (reel/frame and correspondent) was not surfaced before I exhausted my search budget, so those fields are marked [not retrieved]. I have not invented reel/frame numbers, correspondents, or execution dates. This is a partial, source-limited reconstruction, not a certified chain-of-title opinion.

Inventors

• The patent's own assignment record shows both inventors assigning to FIREEYE, INC. on 2008‑11‑03 — the same day the application was filed (USPTO assignment, per Google Patents legal events; assignors of record listed as "AZIZ, ASHAR, STANIFORD, STUART GRESLEY"). This is the standard employee-invention assignment pattern for a venture-backed startup and is consistent with both inventors being FireEye personnel at filing. I could not independently confirm either inventor's employment title from the assignment documents themselves.
• Departure pattern: the assignment records I retrieved say nothing about inventor departures. I therefore cannot confirm or rule out the "inventors departed within 12 months of filing" tell. Stating a departure date would require employment data I do not have — I am not supplying one.
• Inventorship vs. ownership note: neither inventor remains anywhere in the recorded chain of title after the 2008 assignment. All subsequent legs are entity-to-entity.

Original assignee

FireEye, Inc. (Milpitas, CA) — named on the face of US 8,850,571 and the original assignee of record.

• Primary line of business: network security appliances and malware analysis. This patent's disclosed system (tap 115 → heuristic module 130 → scheduler 140 → VM pool 145 → analysis environment 150) is the architectural core of FireEye's flagship Malware Protection System / Web Malware Protection System product line. On the disclosed art, the assignee plainly shipped products embodying the claimed approach — the specification's own "prior art" discussion is written from the vantage point of a vendor commercializing this exact tap-and-replay design. (This is a strong inference from the specification; I did not independently retrieve a product datasheet in this session.)
• Current status: FireEye, Inc. no longer exists as an independent entity. The corporate history recorded in the assignment data is:
  • 2021‑10 — FireEye's Products business (the division that owns this patent) sold to Symphony Technology Group (STG); STG-side IP holder is FireEye Security Holdings US LLC.
  • 2022 — FireEye, Inc. renamed Mandiant, Inc.
  • 2022 — Mandiant, Inc. acquired by Google LLC (Google/government-cloud integration).
  • FireEye Security Holdings US LLC folded into Musarubra US LLC (the McAfee Enterprise + FireEye combination marketed as Trellix).
  • 2024 — Musarubra restructured; IP moved to the Magenta holding entities.
• Bankruptcy: none. The recorded liens are secured financings, not insolvency proceedings.

Assignment timeline

Ordered by recorded date. Only leg (4) has a reel/frame confirmed in my sources.

1. 2008‑11‑03 (executed) / recorded 2008‑11‑03 — Reel [not retrieved]

• Conveyance: Assignment of Assignors' Interest
• Assignor: Aziz, Ashar; Staniford, Stuart Gresley (individuals)
• Assignee: FireEye, Inc.
• Correspondent: [not retrieved]
• Context: Founding-stage inventor-to-employer assignment, executed on the filing date — carries original title into the operating company.

2. 2021‑10‑11 (executed per record) / recorded 2021‑10‑11 — Reel [not retrieved]

• Conveyance: Security Agreement — First Lien Patent Security Agreement
• Assignor: FireEye Security Holdings US LLC
• Assignee: UBS AG, Stamford Branch, as Collateral Agent
• Correspondent: [not retrieved]
• Context: Securitization — patents pledged as collateral for the STG acquisition financing. (Record post-dates the October 2021 STG carve-out close.)

3. 2021‑10‑11 (executed per record) / recorded 2021‑10‑11 — Reel [not retrieved]

• Conveyance: Security Agreement — Second Lien Patent Security Agreement
• Assignor: FireEye Security Holdings US LLC
• Assignee: UBS AG, Stamford Branch, as Collateral Agent
• Correspondent: [not retrieved]
• Context: Securitization — second-lien collateral pledge on the same portfolio.

4. 2022‑09‑15 (recorded) / executed [not retrieved] — Reel [not retrieved]

• Conveyance: Assignment of Assignors' Interest
• Assignor: Mandiant, Inc.
• Assignee: FireEye Security Holdings US LLC
• Correspondent: [not retrieved]
• Context: Divestiture — the products-side patent moves out of the remaining (Mandiant) company into the STG-controlled entity. This is the leg that split this patent from the Mandiant/Google portfolio.

5. 2023‑02‑02 (recorded) / executed [not retrieved] — Reel [not retrieved]

• Conveyance: Change of Name
• Assignor: FireEye, Inc.
• Assignee: Mandiant, Inc.
• Correspondent: [not retrieved]
• Context: Internal reorg — change of name only. No transfer of beneficial ownership. ⚠️ Sequencing anomaly: the name change is recorded after leg (4), in which "Mandiant, Inc." already appears as assignor. The two events are recorded out of corporate sequence; per your literal-interpretation rule I report the record as-is and do not reconcile.

6. 2024‑08‑01 (recorded) — Reel [not retrieved]

• Conveyance: Security Interest
• Assignor: Musarubra US LLC; SkyHigh Security LLC
• Assignee: STG Partners, LLC
• Correspondent: [not retrieved]
• Context: Securitization — interim collateral charge in favor of the PE parent ahead of the August 2024 restructuring.

7. 2024‑08‑13 (recorded) — Reel [not retrieved]

• Conveyance: Merger
• Assignor: FireEye Security Holdings US LLC
• Assignee: Musarubra US LLC
• Correspondent: [not retrieved]
• Context: Internal reorg / upstream merger — IP holder merged into the Trellix operating parent.

8. 2024‑08‑14 (executed) / recorded 2024‑08‑15 — Reel 68657/764

• Conveyance: Assignment of Assignors' Interest (recorded as "Intellectual Property Assignment Agreement")
• Assignor: Musarubra US LLC
• Assignee: Magenta Security Intermediate Holdings LLC
• Correspondent: Susan Zablocki, Kirkland & Ellis LLP, 601 Lexington Ave, New York, NY 10022 — flag: this is the only correspondent I could confirm on this chain, and it appears on a portfolio-wide, multi-hundred-property conveyance, not a patent-by-patent filing. Kirkland & Ellis is a top-tier global corporate/PE firm; one appearance is not a repeat-player finding.
• Context: Transfer-to-holding-vehicle as part of the August 2024 Musarubra restructuring.

9. 2024‑08‑15 (recorded) — Reel [not retrieved; consecutive to 68657/764]

• Conveyance: Assignment of Assignors' Interest (Intellectual Property Assignment Agreement)
• Assignor: Magenta Security Intermediate Holdings LLC
• Assignee: Magenta Security Holdings LLC
• Correspondent: [not retrieved — likely Kirkland & Ellis, but not confirmed]
• Context: Upward transfer to the ultimate holding company — second hop of a same-day two-step.

10. 2024‑08‑15 (recorded) — Reel [not retrieved]

• Conveyance: Security Agreement — First Lien Patent Security Agreement
• Assignor: Magenta Security Holdings LLC; SkyHigh Security LLC
• Assignee: UBS AG, Stamford Branch, as Collateral Agent
• Correspondent: [not retrieved]
• Context: Re-securitization — the portfolio is re-pledged as collateral after the 2024 restructuring.

11. 2024‑08‑16 (recorded) — Reel [not retrieved]

• Conveyance: Release of Security Interest
• Assignor: STG Partners, LLC
• Assignee: Musarubra US LLC; SkyHigh Security LLC (releasing parties)
• Correspondent: [not retrieved]
• Context: Lien release — clears the interim STG charge recorded at leg (6) once the UBS first-lien facility is in place.

Net result: Magenta Security Holdings LLC and Magenta Security Intermediate Holdings LLC are the current recorded owners of US 8,850,571 (consistent with the "Current Assignee" field on Google Patents), encumbered by a UBS AG first-lien security interest recorded 2024‑08‑15.

Timeline diagram

timeline
    title Ownership of US 8850571
    2008 : Filed by FireEye Inc
         : Inventors assign to FireEye
    2010 : Pre-grant publication
    2014 : Patent issued to FireEye Inc
    2021 : UBS first lien security interest
         : UBS second lien security interest
    2022 : Assigned to FireEye Security Holdings
    2023 : FireEye renamed Mandiant Inc
    2024 : STG Partners security interest
         : Merger into Musarubra US LLC
         : Assigned to Magenta Intermediate
         : Assigned to Magenta Holdings
         : UBS first lien security interest
         : STG security interest released

NPE / troll-pattern signals

1. Shell-entity transfer — unclear.
The chain does end in two "…Holdings LLC" entities and the terminal owner of record is a non-operating-sounding vehicle. But naming is not a finding. Every recorded hop into/through the Magenta entities is a corporate-reorganization leg — a Merger (leg 7), an Intellectual Property Assignment Agreement (legs 8–9), and a Change of Name (leg 5) — executed inside a PE-owned operating group (STG → Musarubra/Trellix), not arm's-length sales to an unrelated licensing vehicle. I retrieved no evidence of (i) a licensing-only business model, (ii) a registered-agent service address, or (iii) absence of products. Insufficient evidence to score this present.

2. Known asserter in the chain — not present.
None of Acacia, Marathon, Intellectual Ventures, IPNav, Wi‑LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, or Spangenberg entities appears anywhere in the chain. Every recorded assignee is a FireEye/Mandiant/Musarubra/Magenta or PE/UBS entity. Magenta Security Holdings LLC did not surface on any NPE list in my searches (it surfaces only as the current assignee of the FireEye/Trellix portfolio on Unified Patents' patent pages).

3. Repeat correspondent across the chain — unclear / single data point.
The only correspondent captured is Susan Zablocki, Kirkland & Ellis LLP on reel 68657/764. Kirkland & Ellis is a global general-corporate/PE firm that routinely handles operating-company and sponsor-side patent recordings; a single appearance is expressly not a finding under your recurrence test. I could not retrieve the correspondents for legs 1–7 and 10–11, so recurrence cannot be tested either way.

*4. Cascading transfers — present (moderate).*
Six recordings cluster in a tight window: 2024‑08‑01 (STG security interest) → 2024‑08‑13 (merger) → 2024‑08‑15 (Magenta Intermediate) → 2024‑08‑15 (Magenta Holdings) → 2024‑08‑15 (UBS lien) → 2024‑08‑16 (STG release). Legs 8 and 9 are two chained LLCs recorded the same day (68657/764 being the first of the pair). That satisfies the "multiple consecutive assignments through chained LLCs in <24 months" prong on its face. Caveat: the cascade runs through corporate vehicles inside one PE group, which is why I score it present-but-not-classic rather than a canonical NPE cascade.

5. Pre-litigation transfer — not present.
Consistent with the prior litigation section, no infringement suit naming this patent was found, so there is no first-suit date against which to measure a pre-assertion transfer. The nearest 2024 events (Aug 1–16) are financing/reorg steps, not suit-enablement steps on the record available to me.

6. Bankruptcy fire-sale — not present.
No Chapter 7/11, no 363 sale. The recorded liens (UBS 2021, STG 2024, UBS 2024) are secured financing/collateralization, and the 2024‑08‑16 Release of Security Interest shows the STG charge was satisfied, not foreclosed. This is a leveraged-restructuring signature, not a Kodak/Nortel/Polaroid-style fire-sale.

7. Privateering — unclear.
Privateering would require an operating company transferring to an NPE to assert against competitors, surfaced via SEC/press coverage. I found no assertion activity and no press/SEC record of Magenta asserting this patent. The 2024 transfers read as internal restructuring and collateralization. No evidence either way.

8. Defensive aggregator — not present.
The chain does not terminate at RPX, Allied Security Trust, LOT Network, Unified Patents, or OIN. It terminates at Magenta Security Holdings LLC with a live UBS lien.

Verdict

Insufficient data. ⚠️ Flag: the five verdict options do not cleanly fit this fact pattern — the chain is neither a classic NPE acquisition nor an operating-company assertion suit, and there is more than just the original assignment on record, so the literal definition of "Insufficient data" only partly matches. On the evidence I could retrieve, US 8,850,571 has not been shown to follow an NPE/troll pathway: the chain runs FireEye, Inc. → (change of name) Mandiant, Inc. → FireEye Security Holdings US LLC → (merger) Musarubra US LLC → Magenta Security Intermediate Holdings LLC → Magenta Security Holdings LLC, with every hop being a divestiture, merger, name change, or collateralization inside a PE-owned operating security business, and no litigation or assertion of this patent was identified. The two signals with any traction — the 2024‑08‑01→08‑16 cascading recordings at reel 68657/764 et seq. and the two same-day Magenta LLC legs — are consistent with a leveraged corporate reorganization, not with a troll acquisition. Labeling it an NPE would require evidence (products abandoned, licensing-only business, assertion campaign) that my searches did not produce; I decline to infer it from entity names.

Verification links: USPTO Assignment Center — https://assignmentcenter.uspto.gov/ ; legacy Patent Assignment Search — https://assignment.uspto.gov/patent/index.html (search "8850571" or reel/frame 68657/764). Re-run by exact number there and on Unified Patents' PTAB/litigation portals to close the gaps in legs 1–7 and 10–11 (reel/frame and correspondents still outstanding), and to confirm whether 8,850,571 specifically appears in the schedule of reel 68657/764.

I'll research the prior art citations for US 8,850,571. Let me run targeted searches.

Prior-Art Analysis — U.S. Patent No. 8,850,571 B2

Sources used (all fetched this session): uspto.report grant page (reproduces the USPTO "References Cited" list), https://uspto.report/patent/grant/8850571; Justia, https://patents.justia.com/patent/8850571; Google Patents, https://patents.google.com/patent/US8850571/en.

⚠️ Contradiction flag — earlier sections vs. what the record now shows

The prior "Patent summary" and "Litigation summary" sections correctly flagged that the supplied full text was truncated at step 425 of FIG. 4 and that verbatim claims were unavailable. That flag should now be retired: the USPTO-derived grant record I retrieved does contain the full granted claim set (claims 1–91) and the complete "References Cited" list. Two consequences:

1. The earlier "Plain-Language Overview of the Claims" reconstructed the claims from the Summary section and warned it was not a verified claim chart. The actual granted claims are materially narrower than that reconstruction — the granted independent claims add (i) a "filtering" step, (ii) scheduling of suspicious content "in an order based … on the score … relative to a score associated with another … packet," and (iii) a second threshold different from the first. Any prior-art analysis must key on the granted language, not the Summary.
2. The earlier overview speculated a "system or CRM claim is plausible." Confirmed: the grant contains system claims (36, 62) and a CRM claim (46).

Independent claims in the grant: 1 (method), 36 (system), 46 (CRM), 48 (method), 62 (system), 75 (method), 82 (method). Key common limitations (from claim 1, the paradigm): monitoring in-transit content → identify suspicious characteristic → determine a score = probability the characteristic indicates malicious content → identify as suspicious when score satisfies a first threshold → filter based on that score → execute a VM to simulate receipt/processing, with the filtered content scheduled in an order based on its score relative to another packet's score → analyze VM response, where a second score satisfying a second threshold different from the first confirms maliciousness.

Rule applied: anticipation under 35 U.S.C. §102 requires a single reference to disclose every limitation as arranged in the claim. A reference that discloses only some elements is §103 (obviousness) material, not §102 art. My §102 "which claims" column therefore states the independent claim that is most exposed and, critically, the limitation(s) that reference does not appear to reach. I have reviewed titles, dates, classifications and abstracts — not full texts of each reference — so all statements about disclosure are qualified accordingly.

Effective-date caveats (important, and often overlooked):

• The '571 priority date is 2008-11-03. Only references dated/publicly available before that date are §102(a)/(b) art on their face.
• A large share of the cited U.S. patents issued after 2008-11-03 (e.g., US 8,171,553 issued 2012; US 8,584,239 issued 2013). Those can only be prior art under pre-AIA §102(e) via an earlier effective filing date, which I do not have per-reference.
• The many Aziz / FireEye references (US 8,006,305; 8,171,553; 8,204,984; 8,375,444; 8,516,593; 8,528,086; 8,539,582; 8,549,638; 8,561,177; 8,566,946; 8,584,239; 8,635,696) belong to the same family/inventive entity as the '571. Where a reference and the application share an inventive entity it is not "by another" for §102(e); and pre-AIA §103(c) excludes commonly-owned §102(e)/(f)/(g) art from obviousness. These are the examiner's own-family citations and are weak as anticipatory art.

Tier 1 — Most relevant prior art (detailed)

1. Provos, Mavrommatis, Rajab & Monrose, "All your iFRAMEs Point to Us," Google Technical Report provos-2008a, Feb. 4, 2008 (NPL; also discussed in the '571 Background)

• Full citation: N. Provos, P. Mavrommatis, M. A. Rajab, F. Monrose, "All your iFRAMEs Point to Us," Google Technical Report provos-2008a, Feb. 4, 2008.
• Date: 2008-02-04 (≈9 months pre-filing).
• Description: Large-scale web-malware study. A machine-learning pre-processing phase extracts features from web pages and translates them into a likelihood score; a virtual machine then verifies candidates in a second phase (~0.1% of pages).
• §102 mapping: Discloses the conceptual core of claim 1 steps (b)–(c) and (e)–(f): feature extraction → likelihood score → VM verification. But it does not appear to disclose: (i) monitoring content in transit between a sending and destination system (the report relies on a crawler-built repository — the '571 specification expressly distinguishes this); (ii) a second threshold different from the first; (iii) filtering keyed to the score; (iv) scheduling in an order based on relative scores. It is therefore not a clean anticipatory reference for any independent claim, and the applicant pre-emptively distinguished it in the specification.

2. US 2007/0250930 A1 — Aziz et al., "Heuristic Based Capture with Replay to Virtual Machine," published 2007-10-25

• Full citation: U.S. Pub. No. 2007/0250930 A1 (Aziz et al.), published Oct. 25, 2007 — publication of App. Ser. No. 11/409,355, the parent named in the '571 cross-reference (incorporated by reference).
• Date: published 2007-10-25, i.e., more than one year before the 2008-11-03 filing → potentially a pre-AIA §102(b) statutory-bar reference on its face (note: §102(b) applies to a printed publication irrespective of common inventorship).
• Description: Discloses heuristic-based capture of network content with replay to a virtual machine — the architectural heart of the '571 (heuristic triage → VM replay).
• §102 mapping: Most dangerous reference for the broadest original claims of the '355-family, and closest on: claim 1 elements (a) monitor, (b)/(c) heuristic/score threshold, (e) execute VM. Does not, on its face, disclose the granted '571's added limitations — filtering based on the score + two different thresholds + relative-score scheduling. Best characterized as §102 for the parent's claims and §103/combinational against the '571's independent claims.

3. US 2008/0005782 A1 — Aziz, published 2008-01-03

• Date: 2008-01-03 (pre-filing).
• Description: Same FireEye/Aziz family; network-content capture/detection publication.
• §102 mapping: Same-family, overlapping disclosure; relevant to claim 1 (a)–(c)/(e). Same-family status raises the §102 "by another" and §103(c) common-ownership qualifications noted above.

4. US 7,093,239 B2 — van der Made, "Computer virus screening methods and systems," issued 2006-08-15 (and US 7,657,419 B2, issued 2010-02-02, continuation)

• Full citation: US 7,093,239 B2 (van der Made), Aug. 15, 2006; US 7,657,419 B2 (van der Made), Feb. 2, 2010.
• Dates: 7,093,239 — pre-filing, strong §102 art; 7,657,419 — issued post-filing, only §102(e) if its effective filing predates.
• Description: Computer-virus screening by emulating/simulating a computing platform to execute suspect code and observe behavior.
• §102 mapping: Directly reaches claim 1(e) ("executing a virtual machine to process…") and (f) ("analyzing a response"). Does not appear to disclose the in-transit network monitoring, the probabilistic score, the filtering, the two different thresholds, or relative-score scheduling → §103, not §102, against the independent claims. Strong §103 primary reference.

5. US 6,088,803 — Tso et al., issued 2000-07-11

• Description: Virus detection using an emulated/sandboxed execution environment to observe suspect code behavior.
• §102 mapping: Anticipates the VM-execution/response-analysis concepts (claim 1(e)–(f)) but lacks the network-in-transit monitoring and the score/filtering/two-threshold architecture → §103.

6. US 5,440,723 — Arnold et al., issued 1995-08-08

• Description: Emulation-based detection of computer viruses by executing suspect code in a simulated environment.
• §102 mapping: Earliest VM-emulation teaching in the cited art; relevant to claim 1(e). No network-content scoring/threshold/filtering → §103 background art.

7. US 7,634,714 / 7,779,463 / 7,784,097 / 8,381,299 — Stolfo et al. (Columbia University)

• Dates: 7,634,714 — Dec. 22, 2009; 7,779,463 — Aug. 17, 2010; 7,784,097 — Aug. 24, 2010; 8,381,299 — Feb. 19, 2013.
• Description: Content/payload anomaly detection, worm detection, and detecting malicious payloads using statistical/probabilistic analysis of network payloads — relevant to the "score … probability that the … characteristic … indicates malicious network content" limitation.
• §102 mapping: Most relevant to claims 1(b) (scoring) and 2/3 (Bayesian/corpus). None appears to disclose VM execution + two-threshold + relative-score scheduling → §103 combination material.

8. US 7,069,316 B1 — Gryaznov, issued 2006-06-27

• Description: Protecting a client at runtime from hostile downloadables (network-delivered executable content).
• §102 mapping: Relevant to identifying suspicious downloaded content (claim 1(a)–(b)); lacks VM replay and the two-threshold/null-filtering architecture → §103.

9. US 7,398,388 B2 / US 7,284,278 B2 — Liang, issued 2008-07-08 / 2007-10-23

• Description: Detecting/containing viruses in email attachments (email-delivered malicious content) — relevant to dependent claims 16/19 (email) and 26 (filtered content is email).
• §102 mapping: Reaches "network content includes email" subject matter but not the scoring/VM/threshold core → §103.

10. US 2007/0240218 A1, 2007/0240219, 2007/0240220, 2007/0240222 — Tuvell et al. (Symantec), published 2007-10-18; and US 8,312,545 / 8,321,941 — Tuvell et al., issued 2012

• Description: Malicious-software detection using model/exemplar-based classification of executable content (probabilistic malware decisions).
• §102 mapping: Relevant to the probabilistic scoring limitation (claim 1(b)); no in-transit VM replay/threshold architecture → §103.

11. US 7,418,729 B2 (Szor, 2008-08-26) and US 7,568,233 B1 (Szor et al., 2009-07-28)

• Description: Malicious-code / packed-executable detection — relevant to the "packer"/obfuscation heuristics (claim 1; "eval(unescape(" dependent claims 12/54/68) and to the NPL "Packer" dictionary citation.
• §102 mapping: Reaches obfuscation-detection heuristics but not the network-VM two-threshold core → §103.

12. US 6,357,008 B1 — Nachenberg, issued 2002-03-12 (and US 7,739,740 — Nachenberg et al., 2010; US 8,239,944 — Nachenberg et al., 2012)

• Description: Signature/behavioral computer-virus detection (Symantec). Background for the anti-virus prior art the '571 distinguishes.
• §102 mapping: No network-in-transit VM replay or scoring/threshold architecture → background only.

Tier 2 — Other cited references materially relevant to specific limitations

Appendix — Comprehensive "References Cited" list (as it appears on the face of the grant)

Foreign patent documents: GB 2439806 (Jan. 2008); WO 0206928 (Jan. 2002); WO 0223805 (Mar. 2002); WO 2007/117636 (Oct. 2007); WO 2008/041950 (Apr. 2008); WO 2012/145066 (Oct. 2012).

Selected NPL (beyond Provos): Whyte et al., DNS-Based Detection of Scanning Works (Feb. 2005); Kristoff, Botnets, Detection and Mitigation (Jul. 2005); Costa et al., Vigilante (SOSP '05, Oct. 2005); Kim et al., Autograph (USENIX Sec. 2004); Kreibich et al., Honeycomb (HotNets 2004); Newsome et al., Polygraph (IEEE S&P 2005); Newsome et al., Dynamic Taint Analysis (NDSS '05); Singh et al., Automated Worm Fingerprinting (Dec. 2004); Silicon Defense, Worm Containment in the Internal Network (Mar. 2003); Nojiri et al. (DARPA DISCEX 2003); Moore et al., Internet Quarantine (INFOCOM 2003); Williamson, Throttling Viruses (ACSAC 2002); Apostolopoulos & Hassapis, V-eM (IEEE MASCOTS, Sep. 2006); Baldi & Risso (IEEE ISSPIT, Dec. 2005); Natvig, SandboxII (Virus Bulletin, Sep. 2002); Dunlap et al., ReVirt (OSDI 2002); Chen & Noble, When Virtual is Better Than Real; King et al., OS Support for Virtual Machines (USENIX 2003); Ptacek & Newsham, Insertion, Evasion, and DoS (Jan. 1998); Baecher, Nepenthes (2006); Bayer et al., Dynamic Analysis of Malicious Code (2006); "NetDetector Whitepaper" (2003); U.S. Patent 8,291,499 — Finjan, Inc. v. FireEye, Inc. IPR petition (Jan. 9, 2014); "Packer," Microsoft Computer Dictionary (Mar. 2002).

The complete U.S. patent-and-publication citation list (≈190 patents and ≈190 published applications) appears verbatim on the uspto.report grant page cited above; dates of record include, non-exhaustively, 4,292,580 (1981) … through 8,635,696 (2014), with the Aziz/FireEye family, Liang email-virus patents, and Stolfo/Columbia payload-anomaly patents as the technically salient clusters.

Bottom line

• No cited reference, on its face, discloses every limitation of any independent claim (1, 36, 46, 48, 62, 75, 82) as arranged — chiefly because the granted claims require (i) filtering keyed to the score, (ii) scheduling in an order based on a score relative to another packet's score, and (iii) a second threshold different from the first, none of which the cited art appears to reach in a single reference.
• Strongest §102 candidates are: Provos et al. (Feb. 2008 NPL) and US 2007/0250930 A1 (Aziz — the parent '355 publication, which may be a §102(b) statutory bar), but both fall short of the three added limitations.
• The bulk of the cited art is §103 material, with van der Made (7,093,239/7,657,419), Tso (6,088,803), Arnold (5,440,723) as VM-emulation primary references; Stolfo and Tuvell as scoring/probabilistic-detection references; and Liang/Nachenberg as email/anti-virus background.
• Caveat honored: many cited patents issued after the 2008-11-03 priority date and are only §102(e) art if their effective filing predates it; the same-family Aziz/FireEye patents raise "by another" and pre-AIA §103(c) common-ownership disqualification questions. I could not retrieve per-reference filing dates, and I did not read each reference's full text — so §102 conclusions here are potential, not certified.

I'll first try to recover the actual claim text and the prior-art references cited on this patent's face, since the earlier sections flagged both as missing.

Good — I have the two key references. Now let me try to pull the patent's front-page "References Cited" list and its actual claim text, plus check two more candidate references (HoneyMonkeys and Seifert's static-heuristics work).

Obviousness Analysis — U.S. Patent No. 8,850,571 B2

35 U.S.C. § 103 (pre‑AIA), "Systems and methods for detecting malicious network content"
Prepared 2026 (see date-conflict flag in §0)

0. Scope, sources, and explicit caveats

What I used as the "Prior Art section of this page." The Google Patents rendering supplied to me (https://patents.google.com/patent/US8850571/en) does not contain a References Cited / "U.S. Patent Documents" table — the supplied text is truncated mid‑specification (at step 425 of FIG. 4). What the page does supply as prior art is:

1. The prior art keyword set: network content, suspicious, packets, score, malicious.
2. The Background's admitted prior art: the proxy-based, hold-and-verify approach ("a proxy may be used in the network between the computing device and a web server… the proxy may then process a data exchange including the request and response on a virtual machine and evaluate the virtual machine's response… If no malicious network content is detected, the proxy may forward the requested network content").
3. The Provos et al. citation, discussed by the applicant on the face of the specification.
4. The "Cross-Reference to Related Applications" list (FireEye family filings incorporated by reference).

I therefore build the analysis on those four, and supplement with references located by search, clearly labeled as supplemental, not confirmed as cited-of-record on the '571's face.

Caveats I must state up front:

• ⚠️ Date conflict (flagging per instructions). My operating context states today is 2026‑09‑14; this task states April 26, 2026. I cannot reconcile these and do not attempt to. Nothing in the § 103 analysis turns on the difference.
• ⚠️ Claims still unavailable. Consistent with the earlier Summary section, the authoritative text ends at step 425 and contains no claims section, and my searches did not recover verbatim claim text before I exhausted my search budget. Everything below is analyzed against the claim proxy derived from the patent's own Summary section (elements E1–E6 below), which in this document tracks the Summary nearly verbatim. If the granted claims include narrowing limitations not reflected in the Summary (e.g., specific threshold-tuning or queue-management language), the analysis must be re‑run against that text. This is not a substitute for a claim chart.
• ⚠️ Contradiction with the earlier Litigation/Summary section (flagging). That section described US 8,997,219, US 9,118,715, US 8,990,939, US 9,438,622 and US 9,954,890 as "nominally linked through shared priority." Per the authoritative record as supplied, those applications claim priority to the '571 (the entries read "Priority to US13/011,344," etc.), i.e., the '571 is the parent, and those grants are its children/continuations. The '571 itself claims benefit of no earlier application — it states only that it is "related to co‑pending U.S. patent application Ser. No. 11/409,355." That distinction matters materially to § 103 (see § 6, "effective filing date").

Legal frame: The '571 was filed 2008‑11‑03, i.e., pre‑AIA; § 102/§ 103 as amended by the AIA do not govern its own claims. Pre‑AIA § 103(a) asks whether the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art (POSITA). Graham v. John Deere; KSR Int'l v. Teleflex.

POSITA (proposed): a person with a bachelor's degree in computer science or equivalent and 2–4 years' experience in network security / malware analysis, including familiarity with HTTP content inspection, heuristics/signature matching, and virtualization. A higher-than-average skill level here cuts against the patentee, because it enlarges the corpus of knowledge a POSITA may be presumed to bring to the references.

1. The invention as best understood (element list)

Everything else in the specification (heuristics database 135, scheduler 140, VM pool 145, replayer 205, virtual switch 210, adaptive thresholds, domain profiles, priority queueing, data-object truncation and per-type memory budgets) is, on the Summary-section reading, not claimed subject matter. Those belong to the dependent-claim / children patents (e.g., US 8,990,939 "scheduling analysis of network content").

2. Reference 1 — Provos et al., "All Your iFRAMEs Point to Us" (Google Technical Report provos‑2008a, Feb 4, 2008; also 17th USENIX Security '08)

Sources: https://research.google/pubs/all-your-iframes-point-to-us/; https://static.usenix.org/events/sec08/tech/provos.html; full text PDF at https://scispace.com/pdf/all-your-iframes-point-to-us-4i8f6zsmmu.pdf. Cited on the face of the '571 and expressly discussed in the '571's specification.

Gap: Provos operates on a crawled web repository ("Our goal is to inspect URLs from this repository"), not on traffic in transit. It does not disclose a network tap or packet-level inspection of a live flow. (This gap is precisely the distinction the '571's specification draws — and it is closed by Reference 2.)

3. Reference 2 — Moshchuk et al., "SpyProxy: Execution-based Detection of Malicious Web Content," 16th USENIX Security Symposium, Aug 2007

Sources: https://www.usenix.org/conference/16th-usenix-security-symposium/spyproxy-execution-based-detection-malicious-web-content; full text https://infocon.org/cons/USENIX%20Security/USENIX%20Security%202007/Presentations/SpyProxy...pdf; contemporaneous press coverage https://www.computerworld.com/article/1586240/virtual-sandboxing-provides-safe-security-testing.html.

Key analytical point: SpyProxy is, on its face, the very prior art the '571's Background concedes. The '571's admitted-art paragraph ("the proxy may intercept a request… may then process a data exchange including the request and response on a virtual machine and evaluate the virtual machine's response… If no malicious network content is detected, the proxy may forward the requested network content") tracks SpyProxy's architecture and its stated limitation (≈3 s added latency unoptimized). The applicant's own Background is therefore an admission that E5–E6 (execute VM on suspicious content; analyze the VM's response) and in-transit interception were known.

SpyProxy teaches:

• E1 (in transit): "SpyProxy intercepts and evaluates Web content in transit from Web servers to the browser." — a service deployed in the network infrastructure or client-side; the authors explicitly chose the network-service deployment.
• E2–E4 (functional triage, though scored by safety rather than probability): "On receiving content from the Internet, the SpyProxy front end first performs a rudimentary form of static analysis… The goal of static analysis is simple: if we can verify that a page is safe, we can pass it directly to the client without a sophisticated and costly VM-based check." The analyzer "tries to determine whether the page is active or passive"; "If it cannot identify or process an object, it declares it to be potentially unsafe and submits it to a VM worker for examination." In a 17‑hour departmental trace, 54.8% of HTML pages were passive and therefore skipped the VM.
• E5: a "clean" VMware virtual machine with unnecessary services disabled; "We direct an unmodified browser running in the VM to fetch and render the Web page."
• E6: "triggers" monitoring sandbox violations: "the creation of a new process other than known helper applications, modifications to the file system outside of safe folders…, registry modifications, browser or OS crashes." If a trigger fires, the page is declared unsafe. Behavior-based, not signature-based → detects zero-day.
• Resource management: VM workers are reused (until a trigger fires or 50 requests pass through), the virtual disk lives in RAM, VMs are pre-warmed with a browser already running; content caching and staged release are used to mask latency (50% cache hit rates reported).

Gap: SpyProxy's front-end analysis is a safety determination (safe / potentially-unsafe), not a malicious-probability score against a threshold. Its "conservative" unknown→VM escalation is functionally equivalent triage, but it lacks E3's numeric likelihood score and E4's threshold comparison.

4. Supplemental references (located by search; not confirmed as cited-of-record)

Ref. 3 — Wang et al., "Automated Web Patrol with Strider HoneyMonkeys," NDSS 2006. Per the abstract retrieved (via the SpyProxy paper's reference list, https://www.semanticscholar.org/paper/2d3a3fb3df40502f244b87f15ebc14b54dbd007e): "a pipeline of 'monkey programs' running possibly vulnerable browsers on virtual machines with different patch levels and patrolling the Web to seek out and classify web sites that exploit browser vulnerabilities." Confidence note: I retrieved only the abstract, not the paper; treat the specific teaching as provisional. It is relevant to the "configure the VM to mimic the client" feature in the specification (e.g., scheduler 140 "may identify a web browser running on the client device 110, and retrieve a virtual machine associated with the web browser") — but that feature is not in the Summary-section claim proxy and may not be claimed.

Ref. 3b — Aziz, US 2008/0005782 A1, "Heuristic based capture with replay to virtual machine" (the US 11/409,355 publication; publication date 2008‑01‑03). This appeared in a Google Patents citation listing returned during search (https://patents.google.com/patent/US7464407B2/en). It is the application the '571 identifies as "related" and incorporates by reference, and it discloses heuristic-based capture of network traffic with replay to a virtual machine — i.e., tap/out-of-band capture + heuristics + VM replay. This is the same family and the same assignee (FireEye) and shares an inventor (Aziz). It is timing-qualified prior art (published before 2008‑11‑03), but it raises a § 103(c) common-ownership problem — see § 6.3. Confidence note: I did not retrieve the '782 document itself; I am relying on the citation listing and the '571's own cross-reference paragraph.

Ref. 4 — Not usable. A search returned US 2010/0054278 A1 ("Detecting Payload Anomaly Using N‑gram Distribution of Normal Data," published 2010‑03‑04) appearing on a Unified Patents portal page together with Magenta Security Holdings LLC entries (https://portal.unifiedpatents.com/patents/patent/US-20100054278-A1). Its publication date is after the '571's filing date; absent a verified earlier priority date, I cannot treat it as prior art, and I do not build any combination on it.

5. The combinations

Combination 1 (primary): Provos 2008 + SpyProxy 2007

Provos supplies E2 (feature extraction: out-of-place/zero-pixel iframes, obfuscated JavaScript), E3 (machine-learning likelihood score), E4 (score vs. threshold, empirically derived, conservative, and explicitly calibrated to downstream verification capacity), E5 (VM honeynet running a browser on a clean Windows image), and E6 (behavioral monitoring of file-system, process and registry changes; combined scoring; malicious-vs-suspicious labels).

SpyProxy supplies the missing E1 in-transit posture: interception and evaluation of content in transit from servers to browsers, with the VM analysis performed on content pulled from the live request path — and, crucially, the architectural teaching that a cheap static/triage stage exists solely as a performance optimization for the "sophisticated and costly VM-based check," with unknown content escalated to the VM worker.

Result: the two references together disclose every element of the claim proxy, including the specific ordering the specification emphasizes (cheap score-based triage → escalate only flagged content → VM execution → behavioral analysis), and including the load-aware flavor of the threshold (Provos: threshold chosen "in order to fully utilize the capacity of the subsequent detailed verification phase").

Combination 2: Provos + SpyProxy + Aziz '782 (for emphasis on the tap/out-of-band architecture)

If the claims (or any dependent claim) require that inspection be non-blocking / out-of-band / on a copy of the traffic, Aziz '782 supplies capture of network traffic with heuristic analysis and replay to a virtual machine. See § 6.3 for the § 103(c) caveat.

Combination 3: SpyProxy + Provos + HoneyMonkeys

If any claim requires the VM to be configured to mimic the client device / browser (specification, not Summary), HoneyMonkeys' pipeline of VMs at different patch levels running possibly vulnerable browsers supplies that. Flagged as provisional (§ 4).

Combination 4: Provos + SpyProxy + ordinary-art resource management

For dependent-claim features in the specification but not the Summary — VM reuse/pooling (SpyProxy's "reused until a trigger fires or 50 requests have gone through it"), caching (SpyProxy's Squid front-end, 50% hit rates), pre-emption and minimum execution windows (SpyProxy's rendering timeout with pessimistic unsafe determination; Provos's ~2‑minute VM run) — these map onto the '571's "45 seconds," "predetermined amount of time," and queue-management language.

6. Motivation to combine, element by element (KSR factors)

6.1 Same field, same problem, same solution type. Both references address drive-by-download / web-borne malware — the exact problem the '571's Background frames. Both are, by their own terms, responses to the failure of signature-based AV. KSR: where references are in the same field and address the same problem, and the combination does no more than yield predictable results, the combination is obvious.

6.2 The references expressly motivate the combination. This is unusually strong here, because SpyProxy itself states the motivation: its static analyzer "is just a performance optimization… Content that can be analyzed and determined to be safe is passed directly to the client; content that cannot is passed to a VM worker." That is the design rationale for inserting a lightweight, score-based pre-filter (Provos) ahead of a VM check (SpyProxy). Provos supplies the mirror-image motivation: exhaustive VM inspection "is prohibitively expensive" (billions of URLs), so it "first use[s] light-weight techniques" and picks its threshold "in order to fully utilize the capacity of the subsequent detailed verification phase." A POSITA reading either reference is led directly to the two-stage architecture; no hindsight reconstruction of the '571 is needed.

6.3 Predictable, known techniques. Probabilistic feature scoring over malicious/benign corpora (Provos; and the '571's own approximate-Bayesian log₂(P_f|m)/log₂(P_f|n) formulation is a textbook application of it), threshold comparison, VM execution, and behavioral side-effect monitoring were each individually known and each individually deployed for this exact purpose. KSR: combination of familiar elements according to known methods, yielding no more than predictable results.

6.4 The applicant's own admissions. The '571's Background concedes the proxy+VM approach and criticizes it only for (a) computational intensity / non-scalability and (b) added latency. Both criticisms are addressed by the very references being combined: Provos's scoring triage exists precisely to avoid "prohibitively expensive" exhaustive VM inspection, and SpyProxy's caching/staged-release/VM-reuse optimizations reduce added latency to ~600 ms. An applicant cannot rely on an admitted problem as the non-obviousness hook when the prior art already taught the remedy. Note also that a sibling publication in this family reproduces the same "[0022] In the prior art, a proxy may be used…" admission (https://patentimages.storage.googleapis.com/a9/33/8d/8fa4e34a98b6c9/US20120222121A1.pdf) — I flag that I could not confirm which application this publication belongs to.

6.5 Design incentives / market forces. KSR recognizes that a need or problem known in the field, and design incentives or market forces, can supply the motivation. Here: the need to make behavior-based web-malware detection deployable at network scale (both references state it), plus the specific incentive of tuning the triage threshold to available VM capacity (Provos states it) — which is exactly the '571's "dynamically revised according to… an availability of one or more virtual machines."

6.6 Timing. SpyProxy (Aug 2007) is more than one year before the '571's 2008‑11‑03 filing → pre‑AIA § 102(b) statutory bar; Provos (Feb 4, 2008; USENIX proceedings July/Aug 2008) is § 102(a)/(b) art as of the '571's own filing date. Because the '571 does not claim benefit of any earlier application (see § 6.7), the applicant cannot derive an earlier invention date from the related FireEye filings to antedate either reference.

6.7 Effective filing date — the practical linchpin. The record supplied shows the '571's priority date as 2008‑11‑03, with no earlier priority tie, and the cross-reference paragraph says only "related to" Ser. No. 11/409,355. If that reading is correct, the '571's claims stand on their own 2008 date, and the 2004–2006 FireEye disclosures carry no benefit — which (i) preserves SpyProxy and Provos as prior art and (ii) means the '571 cannot swear behind them. If, contrary to the supplied record, the '571 is in fact a continuation/CIP entitled to 2004–2005 priority, the entire analysis changes and must be redone. This is the single most important factual question to confirm against the file history.

6.8 § 103(c) caveat on the FireEye family art. Aziz '782 (and the other 2004–2008 FireEye applications, e.g., US 2006/0288417‑family and US 7,464,407) are technically § 102(e) art (US application publications filed before the '571's date). But pre‑AIA § 103(c) disqualifies § 102(e)/(f)/(g) art for obviousness where the reference and the application were commonly owned (or subject to a common obligation of assignment) at the time the invention was made. FireEye assigned/owned both. So a § 103 attack built on FireEye's own earlier applications is legally vulnerable — I would not lead with Combination 2/3. Their proper uses are: (a) as evidence of the state of the art and the background knowledge of a POSITA (independent of § 102/§ 103(c)), (b) as the applicant's own admission of the out-of-band, tap-based, replay-to-VM architecture, and (c) for any child/post‑AIA claims where ownership or the AIA § 102(b)(2)(C) common-ownership exception is analyzed differently. Combinations 1 and 3 (SpyProxy, Provos, HoneyMonkeys — all third-party art) are not affected.

7. Counterarguments the patentee will raise, and how they fare

1. "Provos is a measurement study, not a protection system; it crawls repositories, not live traffic." KSR forecloses this: a reference "must be considered for everything it teaches by way of technology" and is "not limited to the particular invention it is describing." More decisively, Provos discloses the verification architecture (VM honeynet, behavioral triggers, calibrated threshold) and the stated reason for triage; SpyProxy supplies in-transit operation. The combination is not merely of the references' stated purposes but of their disclosed techniques.

2. "SpyProxy is the very prior art we improved upon." That is an admission, not a defense: SpyProxy supplies E1 and, on the patentee's own characterization, E5–E6; what SpyProxy lacks (a probabilistic score and threshold) is supplied by Provos. A patent may not be saved by conceding the reference is old while claiming what the reference already taught plus a known optimization.

3. "Provos marks suspicious URLs, and the suspicious classification is our novel step." Provos uses both terms — malicious (threshold met and AV-confirmed) and "suspicious" (threshold met, no AV-confirmed payload). Provos therefore teaches exactly the two-tier flagging the claims recite.

4. Teaching away / determinism. SpyProxy expressly acknowledges non-determinism as a "fundamental limitation" of pre-execution in a VM, and notes the risk that the VM sees a benign ad while the client sees a malicious one. This is the patentee's best non-obviousness fuel: a POSITA could argue SpyProxy cautions against relying on VM pre-execution for protection. Response: SpyProxy does not teach away from the combination; it identifies a limitation and proposes mitigations (log-and-replay, remote display, deterministic rewriting), and it nonetheless reports detecting every threat it examined with only 4 false positives on a 1,909-request workload. A reference's disclosed limitation, coupled with disclosed mitigations and positive empirical results, is not a teaching away. This argument is worth developing if the claims are narrowed to anything about result reuse or replay.

5. Where the patentee has the most room: dependent claims not in the Summary. Assuming the granted claims include limitations such as: (a) the threshold being dynamically revised according to the number of packets to be inspected / VM availability, with synchronized scheduler and heuristic-module thresholds; (b) domain-profile heuristics that suppress VM execution for features previously seen from a domain; (c) priority ordering, pre-emption, and termination of running VMs by priority; (d) de-duplication — deleting queued content already processed within another VM session; (e) per-data-type memory budgets and truncation (1 MB octet/HTML streams; 384 kB images/PDF; 128 kB video). Provos and SpyProxy reach (a) partially (Provos's capacity-calibrated threshold; SpyProxy's caching and VM reuse), and (d) partially (SpyProxy's caching and worker reuse), but (b), (c) and (e) are not well met by these two references. (b) is met by the domain/URL-reputation art (SpyProxy itself discusses SiteAdvisor and blacklists); (c) by ordinary scheduling/quality-of-service art; (e) by ordinary buffer-management art. Any § 103 challenge must be run claim-by-claim against the actual granted text, which I do not have.

8. Confidence and recommended next steps

Recommended steps before this is relied on:

1. Retrieve the granted claims from USPTO PatentCenter / Patent Public Search / the granted-PDF (https://patents.google.com/patent/US8850571/en → Download PDF) and confirm whether the independent claim tracks the Summary, and whether system and CRM claims exist.
2. Confirm the priority chain from the file history: whether the '571 rests solely on its 2008‑11‑03 filing. If it is a continuation-in-part of Ser. No. 11/409,355 with § 112 support for every element, this analysis must be redone against 2005–2006 art.
3. Pull the References Cited table and the examiner's reasons for allowance to see whether Provos and/or SpyProxy were before the examiner — if the examiner distinguished them, the articulated distinction is the target of the rebuttal.
4. Run the § 103(c) analysis on the FireEye-family art (chain of title, common ownership at the time of invention) before deploying Combinations 2/3.
5. Adjacent theory to evaluate: given the dense FireEye continuation family descending from the '571 (US 8,997,219; 9,118,715; 8,990,939; 9,438,622; 9,954,890), assess obviousness-type double patenting and § 112 written-description issues across the family in addition to § 103. This is a separate theory, not a § 103 conclusion.