US 8832832

I'll search for authoritative information on this patent, including any CAFC 2026 docket activity.

US Patent 8,832,832 — Summary

Heading caveat: Below is grounded in the patent full text supplied to me (Google Patents, fetched 2026‑09‑11), corroborated by Justia, Unified Patents, and USPTO‑report/FreePatentsOnline results. Where sources conflict or I lack authority, I flag it explicitly.

Bibliographic data

Abstract (verbatim)

"Systems and methods are presented for generating a threat score and a usage score of each of a plurality of IP addresses. The threat score may be determined based on quantity of occurrences and recency of each occurrence of an IP address in network alert datasets, in addition to a weighting factor for each data source indicating the accuracy of the data source."

Plain-language overview of the independent claims

The granted set appears to be 10 claims with two independent claims (claim 1 and claim 10). Note an important nuance: the issued claim language (per Justia) is narrower/different than the "Summary" wording reproduced on Google Patents, which lists three "aspects" including a non‑transitory medium aspect. I could not confirm a third independent claim from the sources retrieved — treat that as uncertain.

Claim 1 — threat-score system (computer system):

• The system determines an IP address to score.
• It accesses "network alert datasets" from one or more data sources (the data source being a computing system on a network with access to originating IP addresses), each dataset containing recorded threat events with date/time, originating IP address, and event type.
• It identifies which datasets contain occurrences of that IP address (each occurrence = a threat by that IP).
• For each such data source it: (a) counts the occurrences; (b) computes recency, based on time between occurrences and the current time, and further on a cumulative calculation of those time gaps; and (c) determines a weighting factor indicating the likelihood that a perceived threat is an actual threat, grounded in that source's historical data of past threat events.
• The threat score is then derived from quantity + recency + weighting factor. In essence: a time-decayed, source-reliability-weighted aggregation of how often and how recently an IP appears in threat/alert feeds.

Claim 10 — usage-score system (computer system):

• Mirrors claim 1's structure but over "network usage datasets" recording benign/trustworthy usage events (with date/time, originating IP, event type).
• It counts occurrences of the IP, computes recency (again with the cumulative-time-gap calculation), and applies a per-source weighting factor for "likelihood that a perceived threat … is an actual threat" based on historical activity data — i.e., it measures how much an IP looks like a trusted customer/employee/authorized-user address.
• Output is a usage score ("good score"), calculated separately from the threat score so the two do not dilute each other.

Corresponding specification algorithm (context)

The spec adds: source weights cᵢ are estimated percentages of an IP's being involved in an actual threat (e.g., combining two 0.2‑weight sources yields 1−(0.8×0.8)=0.36); time decay may use e.g. Dᵢ(t):=e^C(t−t0) or constant/step/linear/Weibull/hill/smooth‑compact variants; the usage score may be normalized via (2/π)·arctan(kS_usage) into [0,1]; and results are presented as score tables, "bomb" risk ratings, or a two‑dimensional heat map (threat score vs. usage score).

Related family

• US 9,100,428 ("System and method for evaluating network threats"), app. 14/479,863, filed 2014‑09‑08, granted 2015‑08‑04 — same inventor, same abstract; cites '832.
• EP 2,892,197 ("IP Reputation"), Palantir — same abstract.
• Google Patents also lists priority links to US 9,560,066, US 10,230,746, and US 10,805,321.

CAFC / court docket search

No CAFC 2026 docket activity for US 8,832,832 was found. My queries targeting a 2026 Federal Circuit appeal returned zero results, and I found no litigation or Appeal‑docket reference to this patent number. This is a negative result only — my searches were not exhaustive and I did not directly query PACER/CM‑ECF, the CAFC docket system, or Docket Navigator, so I cannot affirmatively state that no such proceeding exists. I recommend verifying against the CAFC docket and PACER if a definitive litigation history is needed.

Items I'd flag for verification: the 2014‑01‑02 vs. 2014‑01‑03 priority-date discrepancy; the exact number of independent claims (2 vs. 3); and whether the claims on Google Patents (Summary wording) were later amended (the Justia language includes added limitations about "cumulative calculation" and "historical data of past threat events" not present in the Summary text).

I'll search for litigation involving US patent 8832832.

The first search returned results for a different "883 Patent" (Sonos v. Google), which is not US 8,832,832. Let me search more specifically.

Let me try more targeted searches on patent litigation databases.

Summary of findings

Based on my searches of patent‑litigation resources (Unified Patents Portal, PTAB/PTACTS materials, and general web searches), I found no known litigation involving US Patent 8,832,832 (Palantir Technologies, "IP reputation").

What I searched and what came back

Conclusion

• Plaintiff(s): None identified
• Defendant(s): None identified
• Jurisdiction: N/A
• Case number: N/A
• Filing date: N/A
• Outcome / status: No litigation identified

No US district court action, ITC investigation, or PTAB (IPR/PGR/CBM) proceeding asserting or challenging US 8,832,832 was found.

Important caveats

1. Search limitations. My searches were not exhaustive. I could not directly query PACER, Docket Navigator, Lex Machina, or the Federal Circuit's docket system in this session, and the tool returned no hits for the specific patent number. A definitive negative would require a paid docket search (e.g., Docket Navigator, Lex Machina) or a direct PACER query for "8,832,832."
2. No auto-correction applied. I did not substitute the similarly numbered Sonos "883" patent result — you asked for the literal number 8,832,832, and that Sonos matter is a different patent.
3. Provenance note. The patent record itself (Google Patents, fetched 2026‑09‑11) shows the patent is Active, an anticipated expiration of 2034‑01‑03, current assignee Palantir Technologies Inc., and a chain of security-interest filings (Morgan Stanley Senior Funding, Royal Bank of Canada, Wells Fargo) — but these are security interests / assignments, not infringement or validity litigation, and should not be counted as lawsuits.
4. Possibility of non-public or recent suits. If a case was filed very recently, it may not yet appear in the free sources searched.

Recommendation: To confirm the negative with certainty, run the exact string "8,832,832" against PACER's nationwide district‑court docket search, the CAFC docket, and PTAB's Patent Trial Proceedings database, and check Docket Navigator/Lex Machina by patent number. If you can share access to any of those, I can help interpret the results.

I'll start by checking the structured source (no ODP proceedings listed) and then run independent searches to see whether any AIA trial proceeding exists that the ODP ingest may have missed.

Searches so far return no IPR/PGR/CBM activity. Let me run a few more targeted queries to be thorough — checking PTAB E2E, Unified Patents, and litigation-driven IPR patterns.

The PTAB documents surfaced so far reference different '832 patents (a 2001-filed Halliburton drilling-fluid patent and a basketball patent), not US 8,832,832. Let me pin down whether any AIA trial actually names US 8,832,832, and check the Unified Patents hit on the EP family member.

US 8,832,832 ("IP reputation") — PTAB / AIA Trial Landscape

Bottom line up front: The USPTO Open Data Portal structured block reports no AIA trial proceedings on US 8,832,832, and my independent web searches found no IPR, PGR, or CBM petition naming this patent, its patent number, or its inventor (Alexander Visbal). The searches did surface several false-friend "'832" patents — I flag those below so nobody conflates them with this one. Treat this as a zero-proceeding patent: no claim has ever been tested at the PTAB.

Proceedings overview

Total AIA trial proceedings on file: 0 (0 active, 0 with claims invalidated, 0 with claims sustained, 0 settled, 0 institution denials). Because no proceeding has ever reached a Final Written Decision (or even institution), every claim of US 8,832,832 stands untested and un-narrowed — the defensive posture is neutral-to-hardened by default, not "claim 1 is dead." There is no FWD, no cancellation certificate, and no PTAB-based estoppel to leverage; a defendant's invalidity case must be built from scratch (and, importantly, may be built freely, since no earlier petitioner has burned the art).

No proceeding to summarize

I have no proceeding number, petitioner, panel, or decision to report, and I will not manufacture one. The per-proceeding template is therefore vacuous for this patent.

⚠️ False positives found in search — NOT this patent (do not cite these as US 8,832,832 proceedings):

• US 8,622,832 (Marty et al., "Trajectory detection and feedback system," basketball sensor patent) — subject of an IPR petition (InfoMotion Sports Technologies) re Pillar Vision. Unrelated to Palantir; number differs by one digit.
• A pre-AIA "'832 patent" in a PTAB POPR referencing a "Wolf" primary reference, Home Depot / FedEx / Lenovo parallel actions, filed 2001-09-27, issued 2006-10-10, now expired. The PTAB filing date and issue date here cannot be US 8,832,832 (filed 2014-01-03, issued 2014-09-09), so this is a different patent — likely the Halliburton / M-I drilling-fluids '832 litigated at the Federal Circuit. Do not conflate.
• EP 2 892 197 ("IP reputation," Unified Patents portal page) — this is the European family member of the same Palantir disclosure (EP app. 14200246.8, priority 2014-12-23), not a US AIA proceeding. A Unified Patents portal record is a patent database entry, not evidence of a challenge. (No EPO opposition has been confirmed either; I have no evidence of one.)

If a defendant's counsel has seen "'832 PTAB activity," it is almost certainly one of the above. Verify the patent number and title on the face of the document before relying on it.

Strategic summary

Claim status. No claim of US 8,832,832 has been canceled, sustained, or otherwise tested at the PTAB — the full issued claim set remains intact and is currently in force (Google Patents lists anticipated expiration 2034-01-03, status Active, assignee Palantir Technologies Inc.). There is no narrowing claim-amendment history from an IPR, so claim construction for this patent has not been shaped by any Board decision. If you are being threatened or sued on it, you are dealing with virgin claims: the § 102/§ 103 strength of the patent is unknown and potentially weak (the disclosure is a 2014-era, arguably § 101-exposed IP-reputation scoring system), but there is no Board precedent on file telling you how the claims read.

Estoppel landscape. Because no petitioner obtained an FWD, § 315(e)(2) estoppel attaches to no one. No prior art has been "burned." Practically, that means a current defendant has a clean slate: every patent/printed-publication § 102 and § 103 ground remains available, and the statutory bars are the usual ones —

• § 315(b): a 1-year clock from service of a complaint alleging infringement (miss it and IPR is barred);
• § 315(a)(1): barred if the petitioner filed a civil action (e.g., DJ) challenging validity before the IPR petition;
• § 315(e): no estoppel yet, since no FWD exists.
  Note the patent issued 2014-09-09, so the PGR window closed 2015-06-09 (§ 321(c)), and CBM review is unavailable — the CBM program sunset for new petitions on 2020-09-16, and this patent is an IP-reputation/network-security patent, not a "financial product or service" claim. IPR (§ 311, patents and printed publications only) is the sole AIA vehicle available today.

Pattern signals. No petitioner has ever targeted this patent; there is no serial-filer pattern, no defensive-aggregator footprint (Unified Patents' only appearance is the EP family patent page, not a filing), and no Patent Owner appellate history to gauge — Palantir has never had to defend this patent at the Board or the Federal Circuit. The recorded security interests (Morgan Stanley, Royal Bank of Canada, Wells Fargo) are collateral assignments, not litigation, and carry no defensive significance. The absence of PTAB activity on a 2014 patent that has been in force for over a decade is itself a mild signal: either the patent has never been asserted in a way that attracted an IPR, or asserters have preferred district-court invalidity. Neither helps or hurts you directly — but it means you cannot free-ride on anyone else's work.

Recommended next steps

1. No FWD to cite. There is no Final Written Decision, institution decision, or settlement to link. I cannot quote a disposition because none exists. Confirm the negative directly at:

   • PTAB E2E / PTAB Center: https://ptacts.uspto.gov (search by patent number 8,832,832)
   • USPTO PTAB Decisions / API: https://developer.uspto.gov/ptab-web
   • CourtListener (for any CAFC appeal, which would be none if there is no FWD): https://www.courtlistener.com
   • Google Patents record (authoritative text used here): https://patents.google.com/patent/US8832832/en

2. If you are a defendant being asserted on US 8,832,832: the absence of prior PTAB art means you have a fresh full IPR toolbox. File the IPR within one year of service of the complaint (§ 315(b)) — and do not file a DJ first, or you forfeit IPR under § 315(a)(1). Prioritize § 102/§ 103 art on "weighting/scoring IP addresses across multiple data sources with recency decay," which is a well-populated 2010–2014 art space.

3. If you are licensing/acquiring around it: the patent is unadjudicated and unamended, so its scope is whatever the claims say (no PTAB-driven narrowing). Budget for a full validity analysis rather than assuming a hardened or a gutted patent.

4. Verification caveat (stated plainly): I hit a web-search step limit before exhausting every query. Everything above beyond the structured ODP block is "no evidence found," not a certified negative. Before relying on it in a filing, run the patent number through PTAB E2E and a litigation database (Docket Navigator / CourtListener) to confirm there is no recently filed, not-yet-indexed petition.

I'll start by pulling the assignment and legal-events data available for this patent from the sources specified.

The first pass gave me legal-event dates but no reel/frame numbers. Let me try the assignment APIs, the Unified Patents portal, and any litigation/asserter data.

I was able to retrieve the Google Patents legal-events record and a corroborating SEC exhibit, but I hit the tool-call limit before I could pull the Assignment Center reel/frame and correspondent fields. I will present what is grounded and explicitly flag what I could not retrieve rather than invent reel/frame numbers.

Assignment & Ownership Analysis — US 8832832 B1 ("IP reputation")

Patent: US 8832832 B1 · Application 14/147,402 · Filed 2014‑01‑03 · Granted 2014‑09‑09 · Anticipated expiry 2034‑01‑03 (per Google Patents legal events)
Current assignee of record (per Google Patents): Palantir Technologies Inc.

⚠️ Data-availability caveat (read before the timeline). The reel/frame numbers and correspondent‑of‑record fields — the two fields you specifically flagged as the highest‑value tells — are not exposed in any of the sources I was able to reach in this session (Google Patents legal events, SEC EDGAR, Unified Patents portal, general web). Assignment Center is an interactive search application and I could not query it directly. I am not fabricating reel/frame numbers or attorney names. Every date below is sourced; every reel/frame and correspondent field is marked [not retrieved].

Inventors

Unusual-pattern check — no signal.

• Only one inventor, so there is no "all inventors departed within 12 months" cluster to detect.
• The inventor's rights moved to Palantir (not away from it); the assignee at filing and the assignee today are the same entity, 12+ years later. That is the opposite of a pre-fire‑sale signature.
• I found no evidence of Visbal departing Palantir, and I could not verify employment history beyond the assignment instrument itself. Treat "Palantir employee" as supported by the recorded assignment, not by independent confirmation.

Original assignee

Palantir Technologies Inc. (Delaware corporation; CIK 0001321655).

• Primary line of business: Enterprise data‑integration, analytics and intelligence platforms (Gotham, Foundry, Apollo). Network/IT security analytics is adjacent to, not identical with, its core analytics business.
• Shipped a product embodying the claims? Not determinable from the record I accessed. US 8832832 describes an internal IP‑reputation scoring system (threat score + usage score, data‑source weighting, decay functions). Palantir ships commercial software, but I found no evidence tying a specific shipped product to these claims, and no evidence the patent is being asserted.
• Current status: Operating, publicly listed (NYSE: PLTR). Not acquired, not dissolved, not in bankruptcy. Google Patents lists Palantir as the current assignee, and the only non‑Palantir parties in the chain are lenders acting as administrative agents holding security interests — these convey no ownership.
• Family note: The continuation family (US 9100428, US 9560066, US 10230746, US 10805321; EP 2892197, EP 3461103, EP 3793165) is all Palantir‑owned per Google Patents family data and the Unified Patents portal entry for US‑10230746 (Original Assignee: Palantir; Current Assignee: Palantir). No family member has been spun out.

Assignment timeline

Recorded ownership transfers away from the original assignee: NONE. Every post‑issuance recording is a security interest, a release, a corrective assignment, or a lender successor‑agent substitution. Below is the full chronological chain of recorded events.

2014‑01‑03 (executed/priority) / filed 2014‑01‑03 — Reel [not retrieved]

• Conveyance: Original application filing / priority
• Assignor: — (application filed by Palantir Technologies Inc.)
• Assignee: Palantir Technologies Inc.
• Correspondent: [not retrieved]
• Context: Initial filing of the application by the original assignee.

[execution date not exposed] / recorded 2014‑07‑28 — Reel [not retrieved]

• Conveyance: Assignment of assignors' interest
• Assignor: VISBAL, ALEXANDER (inventor)
• Assignee: Palantir Technologies Inc.
• Correspondent: [not retrieved]
• Context: Inventor‑to‑company assignment — the standard, expected instrument; not a fire‑sale or reorg transfer. (Recorded ~6 months after filing and ~6 weeks before grant.)

2014‑09‑09 — Publication/grant of US 8832832 B1. No assignment recorded at grant.

2019‑12‑20 (executed, per SEC exhibit) / recorded 2020‑01‑27 — Reel [not retrieved]

• Conveyance: Security interest (grant of lien; not an ownership transfer)
• Assignor: Palantir Technologies Inc.
• Assignee: Morgan Stanley Senior Funding, Inc., as Administrative Agent
• Correspondent: [not retrieved]
• Context: Securitization — collateral filing under a Pledge and Security Agreement dated as of December 20, 2019, tied to a Revolving Credit Agreement dated October 7, 2014. Confirmed by Palantir's SEC filing (EX‑10.2, Trademark/Security Agreement form; same structure for IP collateral). This is a credit facility encumbrance, not a transfer of title.

2020‑01‑27 — Reel [not retrieved]

• Conveyance: Security interest
• Assignor: Palantir Technologies Inc.
• Assignee: Royal Bank of Canada, as Administrative Agent
• Correspondent: [not retrieved]
• Context: Securitization — concurrent lender‑agent collateral filing on the same date as the Morgan Stanley entry.

recorded 2020‑06‑04 — Reel [not retrieved]

• Conveyance: Security interest
• Assignor: Palantir Technologies Inc.
• Assignee: Morgan Stanley Senior Funding, Inc.
• Correspondent: [not retrieved]
• Context: Securitization — further/amended collateral filing within the same credit facility.

recorded 2020‑06‑04 — Reel [not retrieved]

• Conveyance: Release of security interest
• Assignor: Royal Bank of Canada (as agent)
• Assignee: Palantir Technologies Inc.
• Correspondent: [not retrieved]
• Context: Lien release — RBC's security interest discharged; title reverts cleanly to Palantir as to that lien.

recorded 2021‑08‑26 — Reel [not retrieved]

• Conveyance: Corrective assignment (correcting an erroneously listed patent by removing Application No. 16/832,267 from the earlier Release of Security Interest recorded at Reel 052856 / Frame 0382)
• Assignor: Royal Bank of Canada
• Assignee: Palantir Technologies Inc.
• Correspondent: [not retrieved]
• Context: Administrative correction only — a clerical fix to the RBC release, expressly confirming the release of security interest. No change in beneficial ownership.
  • *This is the one concrete reel/frame identifier surfaced anywhere in my sources: the corrected-against release is at 052856/0382.*

recorded 2022‑07‑03 — Reel [not retrieved]

• Conveyance: Security interest
• Assignor: Palantir Technologies Inc.
• Assignee: Wells Fargo Bank, N.A.
• Correspondent: [not retrieved]
• Context: Securitization — new/refinanced credit facility collateral filing.

recorded 2022‑07‑03 — Reel [not retrieved]

• Conveyance: Assignment of intellectual property security agreements (successor agent substitution)
• Assignor: Morgan Stanley Senior Funding, Inc.
• Assignee: Wells Fargo Bank, N.A.
• Correspondent: [not retrieved]
• Context: Agent succession within a securitization — Morgan Stanley's collateral‑agent role passes to Wells Fargo. Title remains with Palantir.

No assignment recorded after 2022‑07‑03. No transfer to any IP‑holding, licensing, or venture LLC appears anywhere in the record.

Timeline diagram

timeline
    title Ownership of US 8832832
    2014 : Filed by Palantir Technologies
         : Inventor assigns rights to Palantir
         : Patent issued as US 8832832
    2019 : Pledge and security agreement signed
    2020 : Security interest recorded Morgan Stanley
         : Security interest recorded Royal Bank of Canada
         : RBC security interest released
    2021 : Corrective assignment recorded
    2022 : Security interest recorded Wells Fargo
         : Morgan Stanley agent role assigned to Wells Fargo

NPE / troll-pattern signals

Verdict

Insufficient data — closest fit; no NPE pattern is supported on the record

Justification: the retrievable ownership record affirmatively shows no NPE signature — the chain never leaves Palantir Technologies Inc., a solvent operating company, and every post‑issuance recording is an encumbrance or administrative act: security interests to Morgan Stanley Senior Funding and Royal Bank of Canada recorded 2020‑01‑27, an RBC Release of Security Interest recorded 2020‑06‑04, a corrective assignment recorded 2021‑08‑26 touching Reel 052856/0382, and Wells Fargo collateral/agent‑succession filings recorded 2022‑07‑03. I nonetheless decline to certify "Operating‑company assertion," because that category requires a current assignee that (a) ships products embodying the claims and (b) is suing actual competitors, and I could not verify either limb — no infringement suit naming this patent was found, and no product‑to‑claim mapping was available. Confidence in any NPE hypothesis is therefore low, and the residual uncertainty is a data‑access limitation (reel/frame and correspondent‑of‑record fields not retrieved), not a conflict in the evidence.

Bottom line for a prosecution/portfolio reviewer: this is a clean, single‑owner operating‑company patent. The security‑interest filings are routine credit‑facility housekeeping and should not be booked as chain‑of‑title transfers in any ownership database. If you need the correspondent names for a repeat‑player cross‑check, that requires a direct Assignment Center pull by patent number.

Verify at:

• USPTO Assignment Center (search patent 8832832): https://assignmentcenter.uspto.gov/
• USPTO Patent Assignment Search (index): https://assignment.uspto.gov/patent/index.html
• Google Patents legal events: https://patents.google.com/patent/US8832832/en
• SEC EDGAR, Palantir Technologies Inc. (CIK 1321655), EX‑10.2 security agreements: https://www.sec.gov/cgi-bin/browse-edgar?action=getcompany&CIK=0001321655
• Unified Patents portal family entry: https://portal.unifiedpatents.com/patents/patent/US-10230746-B2

Notes, limitations, and conflicts in the sources

1. Reel/frame numbers and correspondent names are missing throughout this report. This is a source‑access gap, not an absence of records. The only reel/frame that surfaced is 052856/0382, cited inside the 2021‑08‑26 corrective assignment description as the release being corrected.
2. Execution dates vs. recording dates. Google Patents publishes the recordation date in its legal‑events feed. Genuine execution dates are therefore unknown for the 2014 and 2022 instruments. The one exception is the Pledge and Security Agreement dated "as of December 20, 2019" evidenced by Palantir's SEC EX‑10.2, which aligns with the 2020‑01‑27 recordings.
3. Minor priority‑date discrepancy. Google Patents lists this application's date as 2014‑01‑03; the Unified Patents portal entry for continuation US‑10230746 shows priority 2014‑01‑02 and application date 2017‑01‑29. This is a one‑day family/priority reporting variance and does not affect the ownership analysis.
4. No evidence of litigation. I found no assertion of US 8832832 or its family by Palantir or by any third party. Absence of a found suit is not proof of non‑assertion — a docket‑level search (PACER / Docket Navigator / Unified Patents litigation tab) would be required to state that firmly.

I'll search for the patent and its cited prior art references.

Let me dig into the specific prior-art citations listed on the patent's Google Patents page.

Let me find the actual "References Cited" / Patent Citations section for US 8,832,832 itself.

Prior-Art Analysis — US 8,832,832 B1 ("IP reputation")

1. Identification of the patent (grounded in the record)

There is a same‑family continuation, US 10,230,746 B2, "System and Method for Evaluating Network Threats and Usage" (priority 2014‑01‑02, Palantir). It is not prior art — it shares the same priority and discloses the same subject matter. The same is true of US 9,100,428, US 9,560,066 and US 10,805,321. Per your rule I am not treating any of those as § 102 references.

2. Important verification limitation (please read before relying on the table)

Two caveats must be stated up front, because they affect reliability:

1. The authoritative full text you supplied (the Google Patents rendering of US 8,832,832) does not contain a "References Cited" / "Patent Citations" section. The scrape jumps from the claims/description into the drawings and body text; the front‑page citation block was not included. I therefore could not read the US patent's own back‑citation list directly from the authoritative source.
2. The only machine‑readable patent‑art citation list I could retrieve for this family is the one attached to EP 2,892,197 A1 ("Ip Reputation," Visbal, Palantir, priority 2014‑01‑02) — a family member, not US 8,832,832 itself. Its "Patent Art (3)" list is reproduced below. Back‑citation lists for a US grant and its EP sibling are usually similar but are not guaranteed to be identical; treat the mapping to US 8,832,832 as high‑confidence‑but‑unconfirmed.

Flagged contradiction: the task assumes a set of "patent citations for 8832832." The authoritative document I was given does not contain that set. I am answering from the EP‑sibling citation record plus the NPL block that is visible on the US 8,832,832 front page (via its PDF), and I mark which is which.

Separately, note that the "Cited By (246)" entries surfaced in search (e.g., US 10,609,046, US 10,757,778, US 9,817,563, US 10,462,175, US 10,730,746, etc.) are forward citations — later documents citing US 8,832,832. They post‑date the 2014‑01‑03 priority date and therefore cannot be § 102 prior art against this patent. Do not confuse them with the back‑citation list.

3. Patent-art references (from the family's citation record)

Reference A — US 8,214,490 B1

• Full citation: US 8,214,490 B1, "Compact Input Compensating Reputation Data Tracking Mechanism."
• Dates: priority date 2009‑09‑14; granted 2012 (exact grant day not verified in this session).
• Assignee of record (as listed by Unified Patents): Gen Digital Inc. (successor to Symantec/Norton).
• Brief description: A reputation‑data tracking mechanism that stores and updates reputation information for network entities with a compact, input‑compensating data structure; a general prior‑art reference in the reputation‑scoring space.
• Potential § 102 relevance: the threat‑score claim family (the computer‑system claim and the non‑transitory‑medium claim of the "Summary"/abstract), specifically the concepts of (a) maintaining a reputation store of an entity and (b) computing a reputation value from recorded data about that entity. It is the closest "reputation score from stored observations" reference in the list, but it is directed at compact storage of reputation data generally rather than at per‑data‑source weighting cᵢ, occurrence quantity, and recency decay for IP alerts. My assessment: weak anticipation, stronger as § 103 art.

Reference B — WO 2005/116851 A2

• Full citation: WO 2005/116851 A2, "Electronic Message Source Information Reputation System." (US equivalent cited in the record: US 7,668,951 B2, "Electronic message source reputation information system.")
• Dates: priority date 2004‑05‑24; published 2005 (PCT).
• Assignee of record (as listed): Google LLC (via the IronPort/Postini lineage reflected in the record).
• Brief description: A system that assigns and tracks a reputation to the source of electronic messages (e.g., sending IP addresses) based on observed message behavior, and uses that reputation to classify/direct future traffic.
• Potential § 102 relevance: this is, conceptually, the closest reference to the core "score an IP address from its past observed behavior" idea and therefore most directly bears on the threat‑score claim family. However, its reputation model is event‑count/behavior driven and does not disclose the asserted combination of (i) recency‑decayed per‑occurrence contributions per data source, and (ii) a separate, independent "usage" (trusted‑user) score that is retained un‑diluted. My assessment: potentially anticipatory only for a broad, generic reading of "reputation for a source IP"; not anticipatory of the specific weighted‑decay + dual‑score structure. It is the strongest 102 candidate to argue against if the claim is construed narrowly.

Reference C — US 2010/0235915 A1

• Full citation: US 2010/0235915 A1, "Using Host Symptoms, Host Roles, and/or Host Reputation for Detection of Host Infection."
• Dates: priority date 2009‑03‑11; published 2010‑09‑16.
• Assignee of record (as listed): New York University (NYU).
• Brief description: Detecting a host infection by combining host symptoms, host role, and/or host reputation as signals about the host's state.
• Potential § 102 relevance: the usage‑score claim family is the only plausible target, because "host roles"/trusted‑role concepts are conceptually adjacent to the patent's "customer and employee usage score" and to the claimed "weighting factor … indicating authority of each of the data sources." It does not disclose an independent usage score derived from recorded network usage events of an IP address (VPN logins, proxy hits, white‑list membership). My assessment: not anticipatory of the usage‑score claims; at most § 103 art on the "role/trust as a signal" element.

4. Non‑patent literature actually cited on the US 8,832,832 front page

These are visible on the US patent's own PDF front matter and therefore are confirmed citations of US 8,832,832 (unlike the three items above, which come from the EP sibling). All are web‑analytics / network‑visualization product documentation, printed July 2013 or downloaded May 2014:

• Google Analytics Official Website — Web Analytics & Reporting (printed Jul. 18, 2013, 22 pages)
• KeyLines.com — "An Introduction to KeyLines and Network Visualization" (Mar. 2014, 8 pages); "KeyLines Datasheet" (Mar. 2014, 2 pages); "Visualizing Threats: Improved Cyber Security Through Network Visualization" (Apr. 2014, 10 pages)
• Kontagent Mobile Analytics (printed Jul. 18, 2013, 9 pages)
• Localitys — Mobile App Marketing & Analytics (printed Jul. 18, 2013, 12 pages)
• Mixpanel — Mobile Analytics (printed Jul. 18, 2013, 13 pages)
• Open Web Analytics (OWA) (printed Jul. 19, 2013, 5 pages)
• Piwik — Free Web Analytics Software (printed Jul. 19, 2013, 18 pages)
• StatCounter — Free Web Tracker/Hit Counter/Web Stats (printed Jul. 19, 2013, 17 pages)
• TestFlight — Beta Testing on the Fly (printed Jul. 18, 2013, 3 pages)
• trak.io (printed Jul. 18, 2013, 3 pages)
• UserMetrix (printed Jul. 18, 2013, 3 pages)

§ 102 assessment: These are not anticipatory of any claim. They are cited overwhelmingly to support the specification's generic web‑analytics/visualization boilerplate (the heat‑map reporting module 158 and FIG. 8), not the IP‑scoring algorithm. The KeyLines network‑visualization items are the only ones with any arguable connection to the FIG. 8 heat map, and even those disclose rendering, not scoring. If anything, this odd citation set is itself evidence that the examiner treated the scoring algorithm (weighted per‑source, recency‑decayed, dual threat/usage score) as the point of novelty.

5. Bottom line for the § 102 question

No reference in the retrievable citation record fully anticipates any claim of US 8,832,832 under § 102. The asserted novelty sits in the combination: (1) multiple heterogeneous data sources, (2) a per‑source weighting factor (cᵢ) reflecting historical accuracy/authority, (3) quantity of occurrences of the IP in each source, (4) per‑occurrence recency decay, and (5) two independent scores (threat reputation vs. usage) rather than one blended score — the "high‑threat‑and‑high‑usage = probable false positive" insight of FIG. 4/FIG. 8. None of US 8,214,490, WO 2005/116851 (US 7,668,951) or US 2010/0235915 reaches that combination.

6. What I could not verify (stated explicitly, per instructions)

• I could not open the US 8,832,832 front‑page "References Cited" block directly in this session; the authoritative text supplied lacks it, and my searches returned the EP sibling's citation list rather than the US grant's. The three patent references in § 3 are from EP 2,892,197 A1 and are attributed to US 8,832,832 by family inference, not by direct reading of the US grant.
• I did not verify exact grant dates, full inventor lists, or the complete back‑citation set for US 8,214,490 B1 and US 2010/0235915 A1; I have given priority dates and titles as reported by the Unified Patents record and flagged the grant‑date gaps.
• I did not auto‑correct any identifier. I did not substitute the unrelated Sonos "883 patent" (from the prior litigation section) for 8,832,832, and I did not treat any forward citation or same‑family continuation as prior art.

Recommended next step: pull the USPTO PatentCenter/Patent Full‑Text image for US 8,832,832 directly and read the "References Cited" list on the face of the printed patent; that is the only way to confirm whether the three references above (or different US‑specific references) are the ones actually of record, and to obtain each reference's exact grant date for a precise § 102(a)/102(b) date‑of‑publication argument.

I'll research the prior art cited on this patent and the surrounding art in IP reputation scoring, since the task hinges on grounding combinations in real references.

Good — I found the examiner-cited references from the EP search report. Let me pull details on each and look for the US-side citations.

Now let me identify additional prior art mapping to the claim's distinctive limitations (multi-source weighted aggregation, time-decayed scoring, separate usage/"good" score, heat-map presentation) and check the US-side citations.

I hit the tool-call budget, so this analysis is built on the prior-art record I did retrieve — principally the references cited on the EP family search reports (which are the only prior-art citations I could actually pull for this family) plus the specification text supplied. I flag below, explicitly, what is grounded versus what I could not verify.

Obviousness Analysis — US 8,832,832 B1 ("IP reputation"), 35 U.S.C. § 103

Effective filing / critical date: 2014‑01‑03 (US 14/147,402). No provisional benefit is shown in the record supplied. All references analyzed below pre‑date 2014‑01‑03 by 1.5–9 years, so each qualifies as prior art under §102(a)/(b) without needing the AIA grace‑period analysis. (The 2014‑01‑02 vs. 2014‑01‑03 discrepancy flagged in the earlier bibliographic section does not change the outcome.)

0. Important caveat on the prior-art record — read first

The "prior art" I was able to retrieve for this family is the EPO search‑report citation set for the EP counterparts (EP 2,892,197 / EP 3,463,103 / EP 3,793,165), confirmed on the EPO Global Patent Index page:

Sources: http://data.epo.org/gpi/EP3793165A1-IP-REPUTATION.html; https://portal.unifiedpatents.com/patents/patent/EP-2892197-A1 (same three references, listed as "Patent Art (3)").

Two honest qualifications:

1. I could not retrieve the face-of-patent "References Cited" list for US 8,832,832 itself. My searches for the US citation list returned the EP search report instead. The US examiner may have cited a different (or overlapping) set, and US 9,100,428 (the sibling) has its own citation list I did not pull. The three references below are therefore EPO-cited art applied here by me, not confirmed US examiner-cited art.
2. The EPO marked all three "[A]" — "documents defining the general state of the art," not [X]/[Y]/[E] — and the EP family was ultimately granted (EP 2,892,197, EP 3,463,103, EP 3,793,165 all show as granted/active). That is a meaningful data point against obviousness under the EPO's problem‑and‑solution approach, but it is not dispositive under US law: KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), and its "expansive and flexible" §103 inquiry are broader than the EPO's "could‑would" and problem‑and‑solution framework. I address this tension in §8.

1. Legal framework

• Graham v. John Deere Co., 383 U.S. 1 (1966): scope/content of the claims, differences over the prior art, PHOSITA level, secondary considerations.
• KSR v. Teleflex: a claim is obvious where the elements are known and a PHOSITA would have had a reason to combine them — including where the combination is of familiar elements according to known methods, yields predictable results, or is "obvious to try" from a finite set of identified, predictable solutions. "[A]ny need or problem known in the field … and addressed by the patent can provide a reason for combining the elements."
• Precedent on aggregation/automation: combining two known information‑processing techniques (e.g., a weighted reliability factor + a time‑decay factor) with no change in the underlying operation and no unexpected result is normally obvious. See Dystar Textilfarben v. C.H. Patrick, 464 F.3d 1356 (Fed. Cir. 2006) (same field/same problem); In re Keller, 642 F.2d 413 (CCPA 1981) (combining references for what they fairly teach).
• The claims here are system/medium claims (not means‑plus‑function), so each recited module maps to a step the processor executes.

2. Level of ordinary skill (PHOSITA, as of Jan. 2014)

A bachelor's degree in computer science, electrical engineering, or a related field plus 2–4 years of experience in network security / SIEM / email‑security engineering; or a master's plus 1–2 years. The PHOSITA would be familiar with: IP‑based reputation services (Spamhaus, Cisco/SenderBase, Return Path, DShield/Team Cymru), IDS/firewall/proxy/VPN log formats, Bayesian/probabilistic combination of independent evidence, exponential and other decay functions, and dashboard/heat‑map visualization of scores. That is precisely the profile the three references themselves target.

3. Construction of the three limitations that matter

(a) "the data source comprising a computing system connected to a network and the data source has access to originating IP addresses that correspond to a communication protocol of the network." This is a narrowing limitation added during prosecution — it is absent from the "Summary" wording reproduced on Google Patents (a discrepancy flagged in the earlier section). It effectively requires the data source to be a network‑connected device that logs/observes IP‑layer events. This is broad and is met by any IDS, firewall, proxy, VPN concentrator, or mail gateway.

(b) "recency … based at least in part on an amount of time between respective occurrences … and a current time, and … further … based at least in part on a cumulative calculation of the amount of time between respective occurrences … and the current time." Also added post‑filing; also absent from the Summary text. This is the pivotal limitation. Two readings:

• Broad: recency is aggregated across multiple occurrences (e.g., the spec's Sₙ = 1 − Π(1 − cᵢDᵢ(tᵢ)), a compounding of per‑occurrence aging terms). Under this reading the art reads on it easily.
• Narrow: the system must compute gaps between successive occurrences (inter‑arrival times) and accumulate them, distinct from per‑occurrence age.
  Note the internal tension: the specification's own formula computes each occurrence's age relative to t₀, not gaps between occurrences. That inconsistency matters to §103 (§8 below).

(c) The weighting factor. Claim 1: "likelihood that a perceived threat … is an actual threat … based at least in part on historical data of past threat events for the respective data source." Claim 10 recites the identical threat‑likelihood weighting, even though claim 10 is the usage‑score claim — a drafting oddity I flag in §8.

4. The three references — what they actually teach

4.1 Postini — WO 2005/116851 A2 / US 2008/0016167 A1 ("RTIN" source reputation)

https://patents.google.com/patent/WO2005116851A2; https://patentimages.storage.googleapis.com/.../US20080016167A1.pdf

• Maintains a pool of source IP reputation data (the "Real‑Time Threat Identification Network" database) used to filter network traffic; supports DNS‑type queries and router‑table feeds.
• Multiple heterogeneous data sources feed one reputation engine: a traffic‑monitoring system with a traffic log; a "two‑strikes" system; a "sudden‑death" DHA detector; and an IP‑address information database containing block‑lists, "gray‑lists" of addresses "scored according to their degree of trustworthiness," and lists of trusted IPs.
• Per‑IP scores across event categories ("spam, virus, DHAs … email bombs") on a 1–100 scale → i.e., event type + quantity/degree dimensions per IP.
• Explicit recency reasoning: the two‑strikes system "will check the amount of time that has elapsed since a suspected spam email was last received from that IP address. If a prescribed amount of time or more has elapsed, then … a small likelihood that the suspect email is spam. Otherwise … a greater likelihood."
• Explicit historical‑accuracy / trust‑level reasoning: "assigning trust levels to IP addresses based on anticipated behavior, where the trust levels span many degrees of likelihood that spam would or would not be sent out"; ratings based on historical information; "an IP address can also regain improved ratings … if a notable reduction in spam … is detected over some span of time" (i.e., time‑dependent upward as well as downward adjustment — the "good/usage" counterpart).

4.2 Symantec — US 8,214,490 B1 (Vos), "Compact input compensating reputation data tracking mechanism"

https://patents.google.com/patent/US8214490

• Aggregates notifications from multiple computer systems about content origination from a source, where notifications include "malicious or benevolent content, notifications of blocked content and notifications of received end‑user complaints."
• Computes "running rates" of content origination (total / malicious / virus / spam / blocked / complaints) from a source; the rate "comprises a single number updated using at least an amount of time since the last update to control an influence of new information."
• Explicit time‑weighting of occurrences: "Running rates can be updated based on additional detections … over a period of time since the last update. Older data can be given a higher weight in such calculations." Claim 9: "weighing … previous detections … and current detections … differently."
• Exact "likelihood that a perceived threat is an actual threat" math: computes a "reputation characterization percentage" = malicious/blocked/spam rate ÷ received content rate — i.e., of everything this source reported, what fraction was actually bad — and blocks when it exceeds a threshold (claims 1, 12).
• Claim 5: receipts of "at least one notification that content from a given source was blocked at a given time" → timestamped events.
• Claim 15 expressly lists IP address as a source granularity.

4.3 NYU — US 2010/0235915 A1 (Memon), host symptoms/roles/reputation

https://patents.google.com/patent/US20100235915A1; https://insight.rpxcorp.com/patent/US20100235915A1

• Collects network data from "security alerts from IDSs, IPSs and/or firewalls, various data feeds from routers, switches, and other network equipment," plus "external sources … such as blacklists, Internet routing tables, domain name mappings."
• Determines host‑centric symptoms, roles, and reputation, and computes an infection‑risk / risk score from at least two of those three evidence types (independent claim 1).
• Reputation of a host is inferred from reputations of related hosts (claim 10) — multi‑source evidence fusion.
• Explicitly detects spam‑bot mail‑server roles (claim 11) and peer‑to‑peer node roles (claim 12) → supplies distinct event types including P2P.
• FIG. 2 maps symptoms, roles, and reputation into a Cartesian (multi‑dimensional) space, and FIG. 9 shows an analyst‑facing decision tree → a two‑axis visualization of a bad‑ness measure against a benign/role measure.

5. Element‑by‑element §103 mapping

5.1 Claim 1 (threat score)

5.2 Claim 10 (usage score) and dependents

• Claim 10: Symantec aggregates "benevolent content" notifications alongside malicious ones through the same multi‑source, time‑weighted running‑rate framework — i.e., the disclosed architecture is natively dual‑score (a badness rate and a goodness/benevolence rate). Postini supplies trusted‑IP lists, whitelists, gray‑list trust scores, and trust levels. Combining those teaches a usage/trust score computed separately from the threat score.
• Claim 2 (event types: malicious attack, advertising, P2P, illegal activity, spying): Postini (spam, virus, DHA, email bombs) + Memon (P2P node role; spam‑bot mail‑server; command‑and‑control channels).
• Claim 4 (weighting from quantity/percentage of prior reports that proved to be actual threats): Symantec claim 12's reputation‑characterization‑percentage is essentially this limitation verbatim.
• Claim 6 (data source types: proprietary monitoring, firewall, network‑device access log, mobile hotspot log, VPN access log): Memon's IDS/IPS/firewall/router/switch feeds + Postini's customer/admin data sources; VPN and hotspot logs were conventional enterprise logging.
• Claims 7–8 (recency as a function of elapsed time; exponential/constant/step/linear/Weibull/hill/smooth‑compact decay): Symantec's differential weighting of old vs. new detections and time‑since‑last‑update update rule; Postini's elapsed‑time thresholds (a step decay). The specification itself concedes these are interchangeable known alternatives ("other decay functions can also be used, such as a constant decay, step decay, linear decay, weibull decay, hill decay, smooth‑compact decay function") — which is the classic KSR "finite number of identified, predictable solutions" posture.
• Claim 9 (present a report comprising the threat score): Postini delivers reputation via DNS responses and router tables; Memon's FIG. 2 Cartesian mapping of a host's badness/role/reputation attributes and FIG. 9 analyst decision tree ≈ the two‑axis score report/heat‑map embodiment (FIG. 8).

6. Articulated motivations to combine (KSR rationales)

I would plead these, in roughly descending strength:

1. Same field, same problem, same solution type. All three references are directed to scoring network sources by reputation to filter/block malicious traffic and reduce false positives. Postini's stated purpose is IP‑source reputation filtering; Symantec's is determining "whether to block incoming electronic content from a specific source" based on that source's reputation; Memon's is detecting compromised hosts via reputation. Dystar, 464 F.3d at 1367 (same field/same problem = strong motivation).
2. Both primary references expressly aggregate reports from a plurality of systems. Symantec claim 6 / [0007]: notifications "originating from a plurality of computer systems." Postini: multiple independent data sources (traffic monitor, two‑strikes, sudden‑death, blacklists). A PHOSITA implementing a multi‑source reputation pool (Postini) would naturally adopt Symantec's per‑source running‑rate/percentage machinery, because Symantec's mechanism is designed to be computed per source and designed to aggregate multi‑system reports.
3. Symantec states its own design constraint — compactness — which supplies the reason to bolt it onto a broad IP pool. Symantec: "These running rates are compact, and thus can be maintained for a wide base of sources without requiring a lot of storage." Postini's RTIN database covers IPs and blocks of IPs globally. The combination produces the predictable benefit of scalar, time‑weighted per‑source scores over a large address space.
4. Both references independently identify recency, quantity, and source reliability as the operative variables — i.e., the combination does not add a new variable, it combines variables the field already used. Postini: elapsed time (two‑strikes), volume/degree (per‑category measurements), trust levels. Symantec: rate (quantity/time), time‑since‑update (recency), characterization percentage (reliability). Combining them is a predictable aggregation of known quantities with a predictable direction of effect (more recent/more numerous/higher‑reliability ⇒ higher score).
5. Memon supplies an express, explicit motivation to fuse multiple evidence types: "it becomes difficult to detect attacks in real‑time at the perimeter," and single‑signal approaches "lack comprehensive coverage" — hence "at least two of symptoms, roles and reputation." That is a direct teaching to combine heterogeneous security evidence into one risk score, including firewall/IDS/IPS/router feeds.
6. Obvious to try on the decay function. The patent claims a set of decay functions (claim 8) that it concedes are alternatives. Under KSR, choosing among a small, identified set of predictable candidate functions (exponential vs. step vs. linear) to model aging of threat evidence is obvious, particularly where Symantec already teaches "old data can be given a higher [different] weight."
7. Market/commercial pressure (general knowledge, flagged). During 2004–2013 the industry (SenderBase/TrustedSource, Spamhaus, DShield/Team Cymru, Return Path) converged on exactly this architecture — multi‑feed, IP‑scoped, time‑decayed, source‑reliability‑weighted reputation. I state this as background knowledge rather than as a citable reference in this record, since I did not retrieve a specific document for it.

7. Where the claims are not met on this record, and the strongest non‑obviousness arguments

Honest assessment: no single one of the three references anticipates claim 1 (i.e., §102 is not made out on this record).

• Postini shows multi‑source, IP‑keyed, category‑scored reputation with elapsed‑time reasoning and trust levels — but does not disclose (i) a distinct per‑data‑source numeric weight equal to the probability that a flag is genuine, applied multiplicatively, nor (ii) an explicit cumulative aggregation of occurrence timing.
• Symantec shows per‑source time‑weighted running rates and a fractional "how much of what this source reported was actually bad" figure — but it is source‑centric (an email/HTTP gateway), not an IP‑reputation store spanning heterogeneous log sources, and it lacks the "event type" categorization and the separate trusted/usage dataset architecture as claimed.
• Memon shows multi‑evidence risk scoring and reputation propagation, but not the IP‑reputation scoring formula, per‑source accuracy weights, or time‑decay aggregation.

The best patentability argument for the '832 patent is a narrow‑construction argument on claim limitation (b): reading "cumulative calculation of the amount of time between respective occurrences" as requiring accumulation of inter‑occurrence intervals (successive gaps) rather than per‑occurrence age‑to‑now. Under that reading, Symantec's running‑rate update (which uses time since the last update) and Postini's two‑strikes check (time since the last suspected spam) are each arguably a single elapsed‑time term, not a cumulative multi‑interval computation. This would be the pivot of any §103 defense.

Two countervailing points cut against that argument:

• The specification does not support that narrow construction: the disclosed formula Sₙ = 1 − Π(1 − cᵢDᵢ(tᵢ)) computes each occurrence's age relative to the current time, not gaps between occurrences. That creates a genuine §112 written‑description/enablement vulnerability on the very limitation being used to distinguish the art. A claim term that cannot be construed to cover the only disclosed embodiment is unlikely to be construed narrowly enough to escape the art.
• Even on the narrow reading, the difference is a mathematical implementation detail with no unexpected result, and Symantec's carry‑forward running‑rate is functionally a cumulative time accumulation. KSR's "predictable variation" rationale applies.

The second‑best argument is the dual‑score + two‑axis heat‑map presentation (claim 10 + FIG. 8): Symantec discloses both malicious and benevolent rates, but does not describe displaying them jointly as a threat‑vs‑usage matrix. Memon's FIG. 2 Cartesian symptom/role/reputation space is close, so this is a thin distinction at best; and the claim's own text makes it thinner still (below).

8. Flags, contradictions, and prosecution-level observations

(1) Contradiction with the previously generated "Patent summary" — claim count/independents. The earlier section stated the granted set "appears to be 10 claims with two independent claims (claim 1 and claim 10)" and flagged "2 vs 3" as uncertain. The RPX/Insight claim listing I retrieved for US 8,832,832 B1 shows, in addition to claim 1 and claim 10, a claim 15: "A non-transitory computer-readable storage medium storing computer-executable instructions configured to direct a computing system to:" (https://insight.rpxcorp.com/patent/US8832832B1). That is independent‑claim phrasing. This resolves the flag in favor of three independent claims (1, 10, 15) and against "10 claims total" — the granted set must therefore contain at least 15 claims. I did not retrieve the complete claim set, so the total number remains unverified. All three independents must be addressed in any invalidity contention; the §103 analysis above covers all three because claim 15 tracks claim 1's threat‑score steps in medium form.

(2) Claim 10 is internally inconsistent, and that weakens the dependent‑claim position. Claim 10 (the usage‑score claim) requires a weighting factor "indicating a likelihood that a perceived threat of the IP address in the network usage dataset is an actual threat, wherein the likelihood is based at least in part on historical data of activities associated with each of the respective data sources." It imports threat‑likelihood weighting into the trusted‑usage dataset. Two consequences: (a) it makes claim 10 easier to invalidate, because Symantec's single malicious/benevolent percentage framework teaches applying exactly such a reliability weight to benevolent event streams; and (b) it raises a §112(b) indefiniteness concern about what the weight means for "usage" events. This tension is visible in the earlier summary's observation that the issued claim language differs from the Google‑Patents "Summary" wording.

(3) The US claims are narrower than the EP claims — which cuts for validity in the US but against the "EP granted, so it's non‑obvious" inference. EP 3,793,165 claim 18 recites the weighting as "an estimated percentage of the IP addresses of the data sources that were actually involved in a threat" and recites combining first and second weights — a narrower, more specific formulation than US claim 1's open‑ended "likelihood … based at least in part on historical data." That explains why the EPO could allow the family over the same three references marked [A]: the EPO was assessing a narrower claim set with a problem‑and‑solution framing. It does not establish that the broader US claim 1 is non‑obvious.

(4) The prosecution‑history amendments are the real battleground. The two limitations absent from the Google‑Patents "Summary" text — (i) the data source being a network‑connected system with access to originating IPs and (ii) the "cumulative calculation of the amount of time" recency — plus the claim‑1 "historical data of past threat events" weighting language, were evidently added to overcome art. A full §103 opinion should obtain the file wrapper (USPTO PatentCenter, app. 14/147,402) to determine which references the examiner applied and why these terms were added; the EP search report citations are only a proxy. I could not perform that retrieval here.

(5) Duty of candor / art not of record. Symantec US 8,214,490 B1 is a US patent granted 2012‑07‑03, and Postini's US 2008/0016167 A1 and US 2019/0158515‑family publications are US publications. If any of them is absent from the '832 face‑of‑patent citations, that is material prior art under 37 C.F.R. §1.56 for any later ex parte reexam or IPR. I could not verify the face‑of‑patent list, so I flag this rather than assert it.

(6) No secondary-considerations record found. Consistent with the earlier litigation section's negative result (no district court, ITC, or PTAB proceeding identified involving 8,832,832), there is no objective indicia of non‑obviousness (no long‑felt need testimony, no industry praise, no licensing‑driven nexus) available to rebut this prima facie case. Absent a nexus‑bearing record, secondary considerations do not carry the analysis here.

(7) Post‑grant family may moot some of this. The record shows a continuation line (US 9,100,428; US 10,230,746; US 10,805,321) with claims drifting toward "reliability factor" and "heat map of network addresses" language (e.g., US 2019/0158515 claims 1, 9, 10). Any invalidity position on a §103 basis must be run separately against each family member's claims; the analysis above applies to the '832 claim set as retrieved.

9. Bottom line

Verification items I could not complete and would not assert either way: the face‑of‑patent "References Cited" list of US 8,832,832 and of US 9,100,428; the complete claim set (to resolve the ≥15‑claim question and confirm claim 15 is independent); the prosecution history explaining the added limitations; and whether any US examiner applied Postini, Symantec '490, or Memon. All of these are retrievable from USPTO PatentCenter for application 14/147,402 and the sibling applications, and from the file wrappers of the EP counterparts.