US 10609046

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

Let me verify the claim structure and check for any 2026 PTAB/CAFC activity specifically tied to this number.

US 10,609,046 B2 — Verification-Only Report

Important scoping note: I searched for the exact identifier 10609046 / 10,609,046 and found no 2026 CAFC docket entry, no Federal Circuit appeal, and no PTAB/IPR proceeding naming this patent. My searches surfaced 2026 CAFC/IPR activity for other patents (e.g., U.S. 7,041,786, 11,316,014, 8,458,689), but none for '046. I cannot confirm any 2026 litigation posture for this patent — treat this as absent-from-search-results, not as proof of absence. Note also that your prompt states today is April 26, 2026 while my operating context says September 20, 2026; if the later date is correct, the 2026 docket window I could see is wider than assumed.

Bibliographic data (from the patent's own front page / Google Patents)

Family chain (from the patent's own Cross-Reference section): continuation of Ser. No. 15/228,297 (filed Aug. 4, 2016) → continuation of Ser. No. 14/823,935 (filed Aug. 11, 2015) → provisional 62/036,999 (Aug. 13, 2014). Later continuations shown on Google Patents: 16/822,646 (US 11,201,879 B2), 17/526,953 (US 11,757,905 B2), and 18/360,713 (US 12,192,218 B2 / US 2023/0370483 A1). Related sibling patents in the same family include US 9,419,992 and US 9,930,055 (both titled "Unwanted tunneling alert system").

Minor discrepancy flagged, not auto-corrected: the Unified Patents portal entry for US-10609046-B2 lists a priority date of 2014-08-12, while the patent front page, Google Patents, and the specification all say 2014-08-13. I have not reconciled this.

Abstract (verbatim)

"Various systems and methods are provided that detect malicious network tunneling. For example, VPN logs and data connection logs may be accessed. The VPN logs may list client IP addresses that have established a VPN connection with an enterprise network. The data connection logs may list client IP addresses that have requested connections external to the enterprise network and remote IP addresses to which connections are requested. The VPN logs and the data connection logs may be parsed to identify IP addresses that are present in the VPN logs as a client IP address and in the data connection logs as a remote IP address. If an IP address is so present, user data and traffic data associated with the IP address may be retrieved to generate a risk score. If the risk score exceeds a threshold, an alert to be displayed in a GUI is generated."

The technical problem

The patent's framing: an employee legitimately reaches an enterprise network over VPN, then establishes a second, nested connection — e.g., SSH tunneling over HTTP through the enterprise proxy server — back to a home or third-party device. That second hop is encrypted and looks like ordinary web traffic, so packet sniffers and conventional network monitoring cannot read it. It can be benign (working from home, moving a large file) or malicious (data exfiltration, credential theft/re-entry, or bypassing network content restrictions).

The core inventive move

Rather than trying to decrypt the tunnel, the system correlates two logs that are each innocuous alone:

1. The VPN log — client IPs granted remote access.
2. The proxy/outbound data connection log — client IPs requesting outbound connections, plus the destination remote IPs.

An IP address appearing as a VPN client address in log 1 and as a destination/remote address in log 2 is the signal that a machine inside the enterprise is being called back to from inside the enterprise — i.e., a probable tunnel. That overlap is the gating detection step.

Plain-language overview of the independent claims

The patent has 23 claims across three independent claims, matching the three aspects recited in the Summary: (a) a computing system, (b) a computer-implemented method, and (c) a non-transitory computer-readable medium. Each independent claim carries the same core sequence:

1. Independent claim 1 — Computing system (with dependent claims elaborating the risk-score factors).
A computer processor plus storage holding instructions that cause the system to:

• access a VPN log listing first client IP addresses assigned to remote users granted network access via VPN connections;
• access a data connection log listing second client IP addresses that requested outbound connections and the remote IP addresses those connections went to;
• identify a first IP address that appears in the VPN log as a client IP and in the data connection log as a remote IP (the correlation step);
• determine user data for that IP — user identity, role, geographic location, or access level;
• determine traffic data for that IP — information about connections from the network initiated by that IP;
• generate a risk score from at least the user data and traffic data, the score being at least partly indicative of a likelihood that the traffic includes one or more malicious tunneling connections; and
• generate an alert if the risk score exceeds a threshold value.

2. Independent method claim — Computer-implemented method (recited as performed by systems with hardware and memory). Same six-step pipeline phrased in "source address / destination address" terms: access a first log of source addresses of VPN-granted remote users; access a second log of source addresses requesting outbound connections and the destination addresses; identify an address present in the first log as a source and the second log as a destination; determine user data and traffic data for it; generate a risk score; generate an alert if the threshold is exceeded.

3. Independent non-transitory computer-readable medium claim. Substantively identical instruction set to the system claim, directed to "a plurality of remote users," ending in generation of an alert when the score exceeds the threshold.

Dependent claims (the sub-combinations listed in the patent's Summary) add the following limitations:

• Risk-score factors: geographic mismatch between the device at the first IP and the network's location; employment title; access rights; elapsed time between VPN-connection establishment and tunneled-connection establishment; volume of data transferred over the tunnel; and the type of URL associated with the tunneled connection.
• Port-based scoring asymmetry: if the tunneled connection runs over a first port (e.g., 80/443 — plausibly ordinary web traffic), the risk score is lower than if it runs over a second port (high/uncommon port numbers, e.g., >1000).
• Encryption: the VPN connection and the tunneled connection between the device at the first IP and the network are encrypted.
• False-positive feedback loop: processing feedback on a generated alert, where that feedback affects generation of a second risk score when a second IP address is later identified at the same log overlap and shares characteristics with the first user/traffic data.
• Alert content: the alert includes information at least partly indicating which user data or traffic data caused the threshold to be exceeded.
• GUI generation: generating a user interface (or graphical representation) comprising the alert for display.

Uncertainty I want to flag: the authoritative full claim set is not reproduced in the text I was given, and my searches returned the claim numbering for the parent family publication (US 2016/0050224 A1), which had 20 claims with independent claims at 1, 8, and 15. The issued '046 has 23 claims, so its independent claims are almost certainly numbered differently (plausibly 1, 12, and ~19/20), but I could not verify the exact independent-claim numbers for the '046 patent itself. My plain-language summaries above reflect the substance of the three claimed aspects and the dependent-claim features as recited in the patent's Summary section — they are not a substitute for reading the issued claim set.

Notable prior-art references cited of record (from the patent's reference list)

U.S. Pat. No. 8,788,405 (incorporated by reference and used for the clustering/seed technique for expanding data about a client IP address); Ma et al., "A New Approach to Secure Logging" (ACM ToS, 2009); Schneier et al. secure-logging papers; Waters et al., "Building an Encrypted and Searchable Audit Log"; VirusTotal documentation; and U.S. Pub. Nos. 2016/0050224 (Ricafort et al.) and 2016/0062555 (Ward et al.).

Confidence statement

• High confidence on title, assignee, inventors, application number, filing date (Feb. 8, 2018), issue date (Mar. 31, 2020), priority provisional date, claim count (23), abstract text, and the substance of the three disclosed aspects — all taken from the patent's own front matter and specification supplied as authoritative.
• Medium confidence on the exact independent-claim numbering for the '046 patent (see flag above).
• No confident finding regarding any 2026 CAFC docket or PTAB proceeding involving US 10,609,046; none appeared in my searches, and I will not infer one.

I'll research litigation involving US patent 10609046. Let me run several targeted searches.

Let me search specialized litigation databases and dockets directly.

Summary of Findings

I could not identify any litigation involving U.S. Patent No. 10,609,046.

Based on the searches I was able to run, there is no record of any district court infringement action, Court of Appeals for the Federal Circuit appeal, PTAB proceeding (IPR/PGR/CBM), Section 337 ITC investigation, or other contested proceeding in which U.S. Patent No. 10,609,046 was the asserted or challenged patent.

What the searches actually returned for this patent

The number 10,609,046 appears only in patent-database / bibliographic contexts, not in litigation dockets:

The only "case-like" entries adjacent to the patent number were security-interest reassignments recorded by the USPTO (Royal Bank of Canada, Morgan Stanley Senior Funding, and Wells Fargo Bank, N.A.) — these are lender liens on Palantir's patent portfolio, not infringement litigation. They should not be mistaken for lawsuits.

Key patent-data caveats (interpreted literally)

• The Google Patents record shows a priority date of 2014-08-13 and a filing date of 2018-02-08 (application Ser. No. 15/891,873).
• The '046 patent is a continuation in a family: U.S. App. No. 15/228,297 → App. No. 14/823,935 → Provisional 62/036,999. Related family members appearing in the record include US20180159874A1, US11201879B2, US11757905B2, and US12192218B2.
• Note: certain third-party pages (e.g., some Unified Patents cross-reference pages) display a priority date of 2014-08-12, while Google Patents shows 2014-08-13. I have not auto-corrected either date.

Important limitations on this answer

• I was unable to complete a full sweep of PACER, Unified Patents litigation caselist, RPX/Docket Navigator, CourtListener/RECAP, or the CAFC docket specifically filtered on this patent number before my research steps were exhausted. My searches surfaced no case, but I cannot certify an exhaustive negative result from those databases.
• Palantir Technologies is generally a patent owner rather than a frequent patent plaintiff, and this particular patent (network-tunneling/security monitoring) does not appear in any public enforcement campaign.
• Because Palantir's U.S. patents have occasionally been the subject of petitions for post-grant review filed by Unified Patents (a defensive aggregator), it is possible a PTAB challenge exists that did not surface here, though I found none for the '046 patent.

Bottom line

No known litigation involving U.S. Patent No. 10,609,046 was found in the sources I was able to search. If you need a certified litigation history, I recommend running a paid docket query (LexisNexis / Docket Navigator / RPX) filtered on the exact patent number, or retrieving the patent's full file wrapper and the USPTO Patent Assignment and PTAB records directly — and I'd be glad to interpret those results for you. I did not return results for similar numbers, per your instruction; the items above are tied specifically to 10,609,046.

I'll start from the canonical structured block (no AIA trials indexed) and then probe the web for any proceedings the ODP may not have ingested.

No hits on the target patent so far — one deceptive near-match appeared (IPR2019-00861 is on US 9,300,046, a NuCurrent patent, not this one). Let me verify with two more angles: a PTAB-portal-style query and a check on the patent's family/assignee for IPR activity.

Let me run a couple of final confirmation searches, including the PTAB dockets directly and the patent's family members.

Proceedings overview

Total AIA trial proceedings on file: 0 — no IPRs, no PGRs, no CBMs, no derivation proceedings (active: 0 / claims invalidated: none / claims sustained: none / settled: none / institution denied: none). The patent is therefore completely untested at the PTAB and un-narrowed: all 23 issued claims stand exactly as granted, so a defendant gets neither the gift of canceled claims nor the § 315(e)(2) estoppel shield that a prior petitioner would have handed over — the validity fight is unexplored territory, and you would be the first mover if you file.

Proceedings detail

There are no proceedings to detail. I am stating that plainly rather than padding the template with empty headings, because fabricating an IPR number, panel, or FWD disposition here would be the single most damaging thing this memo could do.

What I checked and what I relied on:

1. Canonical source (controlling): the structured "PTAB proceedings on file" block derived from the USPTO Open Data Portal returns no AIA trial proceedings for US 10,609,046. Per the operating rules, that is the default answer.
2. Web corroboration: targeted searches for an IPR/PGR/CBM naming US 10,609,046, its assignee Palantir Technologies Inc., its inventors (Ricafort, Singh, Martin), and its title ("Unwanted tunneling alert system") surfaced no petition, no institution decision, no Final Written Decision, and no appeal. Google Patents' procedural timeline for the patent (https://patents.google.com/patent/[US10609046B2](/patent/US10609046B2)/en) shows only prosecution, terminal disclaimer, and security-interest reassignments (Royal Bank of Canada 2020‑01‑27; Morgan Stanley Senior Funding 2020‑01‑27; Wells Fargo 2022‑07‑03) — no "PTAB" or "IPR" events.
3. Family sweep: the same search found no AIA trial on any member of this continuation family — US 9,419,992 (app. 14/823,935, filed 2015‑08‑11), US 9,930,055 (app. 15/228,297, filed 2016‑08‑04), US 11,201,879 (app. 16/822,646, filed 2020‑03‑18), US 11,757,905 (app. 17/526,953, filed 2021‑11‑15), US 12,192,218 (app. 18/360,713, filed 2023‑07‑27), or the pending publication US 2023/0370483 A1. That matters because an IPR attack on the '046 alone leaves the sibling continuations alive.
4. Defensive-aggregator check: the patent does appear on Unified Patents' public patent-tracking portal (portal.unifiedpatents.com/patents/patent/US-10609046-B2), but that is a monitoring/analytics page, not an Unified Patents IPR petition. Unified's litigation posture (independent of members, e.g. IPR2020‑01201 Unified v. MasterObjects) is a general pattern signal, not a proceeding on this patent.

⚠️ Decoys — do not cite these as proceedings on US 10,609,046

My searches repeatedly surfaced PTAB cases that share the trailing digits "046" or that involve Palantir-adjacent security patents. None of these involve US 10,609,046 — verify the patent number before any of these ends up in a brief:

The "‑046" collision (US 9,300,046 vs. US 10,609,046) is exactly the kind of transcription error that gets a defendant sanctioned; quote the full number.

Strategic summary

Claim status: 100% UNTESTED. No claim of US 10,609,046 has ever been canceled, confirmed, or construed by the PTAB. All 23 claims (per the granted patent's "23 Claims, 7 Drawing Sheets") remain in force, with the terminal disclaimer noted on the face of the patent and the ODP-reported anticipated expiration of 2035‑08‑11. There is no "surviving claims" list to give you, because nothing was ever cut. The flip side: there is also no PTAB claim construction or invalidity record you can mine, and no adjudicated narrowing that limits how broadly Palantir or a successor can read the claims.

Estoppel landscape: a blank slate — which is both an opportunity and a warning. Because no petitioner has ever reached a Final Written Decision on this patent, no § 315(e)(2) estoppel has attached against anyone, and there is no privity chain to inherit. For a defendant being asserted against today, every prior-art ground is nominally still available: § 102 anticipation, § 103 obviousness, and § 112 written-description/enablement (the specification's risk-score factors are largely expressed as optional "may be based on" alternatives, which is fertile § 112 territory). Conversely, you cannot ride anyone else's work — you would be building the invalidity case from scratch. Note the procedural clocks: PGR is unavailable (§ 321(c)'s nine-month post-grant window closed around 2020‑12‑31 for this 2020‑03‑31 grant), CBM is unavailable (AIA § 18 sunset for new petitions on 2020‑09‑16), leaving IPR (§§ 311–319) as the only AIA trial vehicle — and your § 315(b) one-year clock starts on service of a complaint alleging infringement of this patent, not on some other patent in the family.

Pattern signals: the striking signal here is the absence of a pattern. This is an operating-company patent (Palantir Technologies Inc., Denver) in a heavily asserted technology zone (network security / tunneling detection), it has never (to my search) been the subject of a public infringement suit that drew an IPR, and the family has been kept deliberately wide — the '046 issued 2020‑03‑31 off a continuation chain, then Palantir filed two more continuations (2020‑03‑18 → US 11,201,879; 2021‑11‑15 → US 11,757,905) and a further application (2023‑07‑27 → US 12,192,218, issued 2025‑01‑07). That continuation strategy is itself the most important defensive fact: invalidating the '046 does not clear the field — the same disclosure sits in at least four other live or granted U.S. patents, so any serious IPR campaign would need to be family-wide and budgeted as such. No Unified Patents IPR, no aggregator challenge, and no repeat-petitioner pattern exists.

Recommended next steps

If you are a defendant and are looking for something to point at: there is nothing to point at. Unlike the "claims 1‑5 have been canceled — the demand letter cites dead claims" posture, no FWD exists to quote, and I will not manufacture one. Do not let an opposing brief or an internal draft assert that this patent has "survived IPRs" or "been invalidated" — both would be false. The accurate statement of record is: US 10,609,046 has never been challenged in an AIA trial; all 23 claims stand as issued.

If you are preparing to file: you are the first mover, which means (a) full freedom to choose grounds with no estoppel shadow, but also (b) no § 315(b) bar to worry about only until you are served — docket the one-year date from service of any complaint asserting this patent. An IPR petition must be on file within that year; institution is decided within six months of the petition's filing (§ 314(b)), and once instituted, the Board's statutory one-year FWD deadline runs from the institution date (§ 316(a)(11)). Plan expert declaration work backward from those two dates.

Prosecution-history and family work before you file:

• Pull the complete file histories of the '046 and its parent US 9,930,055 (app. 15/228,297) — the earlier allowance (Notice of Allowance for app. 15/207,343 dated 2018‑04‑03 appears in the '046's listed references) will reveal examiner-cited art and any narrowing amendments that cut against a broad reading.
• Because a single-patent IPR leaves the continuation siblings intact, map the claim scope of US 11,201,879, US 11,757,905, US 12,192,218, and pending app. 18/360,713 before committing budget. Statistically, well-asserted operating-company patents in this zone eventually attract IPRs; the absence of one here may reflect commercial posture rather than patent strength.

Where to verify (rather than take my word): the patent page at https://patents.google.com/patent/US10609046B2/en, the Board's public E2E system at https://ptacts.uspto.gov/, and a RECAP docket search at https://www.courtlistener.com/?q=%2210609046%22&type=r for any district-court or Federal Circuit filings. A Federal Circuit appeal is only possible from a Board decision or a district-court judgment; there has been neither, so there is no CAFC docket and therefore no CourtListener opinion for me to link.

Caveats I will not paper over: (1) I could not directly query PTAB E2E or a commercial PTAB docket (Docket Alarm) in this session; my conclusion rests on the controlling ODP structured block plus web corroboration, and ODP ingest can lag. A very recently filed, not-yet-indexed petition cannot be ruled out — re-verify against E2E before relying on this in a filing. (2) I intentionally did not characterize independent claim numbers or the exact claim set, because the claims column was not included in the fetched patent text; treat "claim 1 is a system claim" as an inference from the specification's aspect headings, not a verified quotation.

I'll research this patent's assignment record and litigation history before assembling the report.

Let me dig for the specific recorded assignment reel/frame numbers and any litigation or NPE involvement.

Let me try to pin down the specific reel/frame numbers and the correspondents of record.

Assignment & Ownership Analysis — US 10,609,046 B2 ("Unwanted tunneling alert system")

Scope note / data provenance: I was able to retrieve the prosecution chain and the Google Patents legal-events record for this patent, and I cross-checked secondary sources (Unified Patents portal, patentleaderboard, SEC/EDGAR-linked credit agreements). I could not pull the individual reel/frame numbers or the recorded correspondent for this patent's entries — the Assignment Center interface and the legacy assignment PDFs for this specific serial were not reachable in this session, and I will not fabricate reel/frame data. Everything below that is stated is anchored to a dated record; gaps are flagged as gaps.

Inventors

Unusual-pattern check: None detected. The classic "all inventors leave within 12 months of filing → fire-sale" tell is absent. Ricafort and Martin both continued to accrue Palantir patents for roughly a decade after this 2015 filing (Ricafort through early 2025), which is the opposite of a departing-inventor pattern. Source: https://www.patentleaderboard.com/palantir-technologies/juan-ricafort/[541446](/patent/541446) and /philip-martin/651801.

(Minor discrepancy to log: Google Patents lists the priority date as 2014-08-13 — the provisional, App. 62/036,999 — while the Unified Patents portal lists 2014-08-12. I did not resolve which is correct.)

Original assignee

Palantir Technologies Inc. (the entity named on the issued patent).

• Line of business: Enterprise data-analytics / software. Flagship platforms Gotham, Foundry, Apollo, AIP.
• Product embodying the claims: Uncertain. The claims cover log-correlation to detect malicious VPN tunneling and initiate termination of a connection (claim 1 of the later continuation, US 2023/0370483). This reads as internal information-security tooling rather than a named commercial SKU. I could not confirm any commercial product sold on these claims.
• Current status: Operating, publicly listed. Went public via direct listing on NYSE (PLTR) on 2020-09-30. Not acquired, not dissolved, not in bankruptcy. Financially healthy — the security-interest events below are ordinary secured-lender collateral pledges, not distress filings.
• Original assignee entity details on earlier family filings: "Palantir Technologies Inc., a California corporation having offices at 100 Hamilton Avenue, Suite 300, Palo Alto, CA 94301" (per Palantir combined declaration & assignment forms captured in other, unrelated Palantir records).

Assignment timeline

Chain of title, in recording order, from the Google Patents legal-events record (https://patents.google.com/patent/[US10609046B2](/patent/US10609046B2)/en). Reel/frame numbers were not retrievable and are shown as not available; I did not invent them. No ownership conveyance ever moved this patent away from Palantir.

• 2020-01-27 (recorded) — Reel/Frame not available

  • Conveyance: Security Agreement / Security Interest (grant of collateral)
  • Assignor: Palantir Technologies Inc.
  • Assignee: Royal Bank of Canada, as Administrative Agent
  • Correspondent: not available
  • Context: Financing — Palantir pledged its patent portfolio (incl. this patent) as collateral under its senior secured revolving credit facility.

• 2020-01-27 (recorded) — Reel/Frame not available

  • Conveyance: Security Agreement / Security Interest
  • Assignor: Palantir Technologies Inc.
  • Assignee: Morgan Stanley Senior Funding, Inc., as Administrative Agent
  • Correspondent: not available
  • Context: Financing — parallel collateral record to a successor/co-agent under the same credit facility.

• 2020-06-04 (recorded) — Reel/Frame not available

  • Conveyance: Release of Security Interest
  • Assignor: Royal Bank of Canada
  • Assignee: Palantir Technologies Inc.
  • Correspondent: not available
  • Context: Lien release — RBC's collateral interest discharged in connection with the 2020 credit-facility amendment (Amendment No. 8, dated 2020-06-04).

• 2020-06-04 (recorded) — Reel/Frame not available

  • Conveyance: Security Agreement / Security Interest
  • Assignor: Palantir Technologies Inc.
  • Assignee: Morgan Stanley Senior Funding, Inc.
  • Correspondent: not available
  • Context: Financing — re-perfected collateral grant to the continuing administrative agent.

• 2021-08-26 (recorded) — Reel/Frame not available

  • Conveyance: Corrective Assignment (correction to the release of security interest previously recorded at Reel 052856 / Frame 0382, removing an erroneously listed application)
  • Assignor: Royal Bank of Canada
  • Assignee: Palantir Technologies Inc.
  • Correspondent: not available
  • Context: Administrative correction only — no change in ownership. (Note: the reel/frame cited inside this correction, 052856/0382, is quoted verbatim from the record text; it is the corrected-against record, not independently verified by me for this patent.)

• 2022-07-03 (recorded) — Reel/Frame not available

  • Conveyance: Assignment of Intellectual Property Security Agreements (agent succession)
  • Assignor: Morgan Stanley Senior Funding, Inc.
  • Assignee: Wells Fargo Bank, N.A.
  • Correspondent: not available
  • Context: Financing — Wells Fargo succeeded Morgan Stanley as administrative agent under the amended credit agreement (Amendment No. 13, dated 2022-07-01).

• 2022-07-03 (recorded) — Reel/Frame not available

  • Conveyance: Security Agreement / Security Interest
  • Assignor: Palantir Technologies Inc.
  • Assignee: Wells Fargo Bank, N.A.
  • Correspondent: not available
  • Context: Financing — collateral grant to the new agent.

• 2023-07-26 (recorded) — Reel/Frame not available

  • Conveyance: Assignment of Assignors' Interest (inventor → company)
  • Assignors: Juan Ricafort; Harkirat Singh; Philip Martin
  • Assignee: Palantir Technologies Inc.
  • Correspondent: not available for this record. (Contextual note, clearly flagged: Palantir inventor-assignment forms in other families are consistently recorded through Sheppard Mullin Richter & Hampton LLP, Customer No. 143846 — e.g. the "Machine Fault Modelling" assignment at Reel 046654/0931. I could not confirm Sheppard Mullin as the correspondent on this patent's records, so this is a lead, not a finding.)
  • Context: Original/confirmatory inventor assignment — notably recorded ~8 years after the 2015 non-provisional filing, and one day before the 2023-07-27 filing of continuation US 18/360,713. Whether this is a late first recording or a family-level re-recording for the new continuation is unclear from the sources available.

Do-not-infer guardrail: Between 2015 and 2023 the only records for this patent are (a) the inventor→Palantir assignment and (b) lender security interests, releases, an agent-succession record, and a corrective assignment. There is no recorded conveyance of title to any third party in this chain.

Timeline diagram

timeline
    title Ownership of US 10609046
    2014 : Provisional application filed
    2015 : Non-provisional filed by inventors
         : Inventors assign rights to Palantir
    2016 : Continuation filed
    2018 : Continuation filed
    2020 : Patent issued to Palantir
         : Security interest to Morgan Stanley
         : Security interest to Royal Bank of Canada
    2021 : Corrective release recorded
    2022 : Wells Fargo becomes agent
    2023 : Inventor assignment recorded
         : New continuation filed

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT. No "IP / Holdings / Licensing / Ventures" LLC appears anywhere in the chain. Every record is either the operating company (Palantir), the inventors, or a bank acting as administrative agent. The lender entities (RBC, Morgan Stanley, Wells Fargo) take collateral, not title — no commercial-product gap to fill.

2. Known asserter in the chain — NOT PRESENT. No assignee matches Acacia, Marathon, IV, IPNav, Wi-LAN, Conversant/Mosaid, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, or any Spangenberg entity. The only non-bank assignee is Palantir Technologies Inc., which is not on any public high-frequency-plaintiff list I could surface, and its Unified Patents portal page (https://portal.unifiedpatents.com/patents/patent/US-[10609046](/patent/10609046)-B2) lists it simply as assignee with no assertion flag.

3. Repeat correspondent across the chain — UNCLEAR. I could not retrieve correspondent-of-record data for any of this patent's eight recorded entries, so I cannot test recurrence. I decline to assert a finding. The only related datum is the separate-family Sheppard Mullin pattern noted above, which is not sufficient to call a signal here.

4. Cascading transfers through chained LLCs — NOT PRESENT. There are no successive ownership assignments at all; the only "chain" is lender-agent succession (Morgan Stanley → Wells Fargo), which is an administrative-agent substitution, not a transfer of patent title.

5. Pre-litigation transfer — NOT PRESENT. I found no infringement suit naming US 10,609,046, and no assignment within 6 months preceding any suit. The nearest-in-time transfer event (2023 inventor assignment) is an intra-company confirmation recorded alongside a new continuation filing, not a transfer to an asserter.

6. Bankruptcy fire-sale — NOT PRESENT. Palantir was never in Chapter 7/11; it completed a NYSE direct listing on 2020-09-30. The 2020/2022 security-interest records arise from ordinary secured lending under a revolving credit facility first dated 2014-10-07 (per the 2021-04-02 8-K exhibit), not from insolvency.

7. Privateering — NOT PRESENT. No transfer to an assertion vehicle, and no SEC/litigation evidence of Palantir funding suits against competitors through a proxy.

8. Defensive aggregator (anti-NPE) — NOT PRESENT. The chain does not terminate at RPX, AST, LOT, Unified Patents, or OIN. (Note: the Unified Patents portal merely displays this patent; that is not ownership by Unified.)

Verdict

Insufficient data (per the task's definition: only the original assignment — i.e., no NPE chain to report).

Justification: The complete recorded ownership history for US 10,609,046 consists of the inventors' assignment to Palantir (recorded 2023-07-26) plus a series of 2020–2022 lender security interests, releases, agent-succession and corrective records (RBC and Morgan Stanley agents, 2020-01-27/2020-06-04; Wells Fargo as successor agent, 2022-07-03) — none of which conveys title to a third party, and none of which touches a recognized NPE or defensive aggregator. Because the patent never left the operating company and has no assertion record, there is no NPE pattern to substantiate; the only reason I do not select "Operating-company assertion" is the absence of any evidence that Palantir is enforcing these claims, and the only reason I do not select a defensive-aggregator verdict is that the chain simply ends at Palantir. Caveat: I could not retrieve reel/frame or correspondent-of-record values for any entry, so any future check of Assignment Center should confirm the recording metadata before this is treated as final.

Verify at: USPTO Assignment Center — https://assignmentcenter.uspto.gov/ (search "10609046"), and the Google Patents legal-events tab — https://patents.google.com/patent/US10609046B2/en.

I'll research the prior art citations for US Patent No. 10,609,046. Let me run several targeted searches.

I found the key citation data. Let me verify the exact citation list for US10609046 from additional sources and get details on each reference.

Prior Art Analysis — U.S. Patent No. 10,609,046

1. Identification and scope

Caveat up front: I could not retrieve the front-page "References Cited" of the '046 patent verbatim from the USPTO image. The citation lists below are taken from the Google Patents record for this family and from uspto.report, and I have flagged wherever I could not independently verify an item. Where a claim number would be required, I note that the exact claim numbering of US 10,609,046 is not reproduced in the data I could retrieve; I therefore map to the independent claim groupings (system / method / CRM), which are the three independent aspects reflected in the specification's Summary.

2. Claims to be mapped

Per the specification's Summary and claim-like text, the '046 patent has (at least) three independent claims covering the same core sequence:

1. access a VPN log listing first client IP addresses (VPN client IPs);
2. access a data-connection (proxy) log listing second client IPs that requested outbound connections and remote IP addresses of those connections;
3. identify a first IP address present in the VPN log as a client IP and in the data-connection log as a remote IP;
4. determine user data (identity, role, geographic location, access level);
5. determine traffic data (connections from the network initiated by the first IP);
6. generate a risk score based on the user data and traffic data; and
7. generate an alert if the risk score exceeds a threshold.

The system independent claim (with corresponding CRM claim) recites the above; the method independent claim recites the same steps as a computer-implemented method. Dependent/aspect features include: geographic mismatch; employment title; access rights; VPN-to-tunnel timing; data volume; URL type; port-based weighting (lower risk on port 80/443); encryption; and feedback that affects later risk scores.

3. Cited patent references

Google Patents reports five (5) patent citations for this family (shown on the US 10,609,046 / related family record). These are the references most relevant to the § 102 analysis.

3.1 US 8,448,247 B2 — Adaptive behavioral intrusion detection systems and methods

• Assignee / inventor: Global Dataguard, Inc. (Michael Stute et al.)
• Dates: Earliest priority 2002-03-29 (Prov. 60/368,629); PCT/US2003/09543 filed 2003-03-28; US national-phase continuation chain (13/453,879 filed 2012-04-23); granted 2013-05-21.
• Description: Establishes a "normal behavior"/baseline from historical network traffic, monitors traffic to detect deviations, rates/scored packets by their deviation from the norm, and generates an alert when a rating meets a threshold; also discloses a human-assigned score combined with an alert "strength" and escalation logic, and mentions VPN tunnels connecting the sensor to the network.
• Claim(s) potentially implicated:
  • The "generate a risk score … " and "generate an alert if the risk score exceeds a threshold value" elements of the independent system/method/CRM claims, and the feedback dependent feature ("receiving a human-assigned score … reflective of a prediction accuracy").
  • § 102 assessment: Not a clean anticipation of the independent claims — it does not disclose accessing a VPN log, accessing a separate outbound data-connection/proxy log, or correlating the same IP as both a VPN client IP and an outbound remote IP. Best characterized as a § 103 reference against the scoring/alerting/threshold/feedback aspects.

3.2 US 2006/0031928 A1 — Detector and computerized method for determining an occurrence of tunneling activity

• Inventor: James W. Conley
• Dates: filed 2004-08-09; published 2006-02-09.
• Description: Directly targets tunneling detection through a firewall. Establishes a set of norms for network traffic, monitors a series of packets, and analyzes attributes (average outbound packet length, connection/series duration, connection frequency, keywords in non-TCP packets, encryption in ICMP/UDP, connection source IP address and destination IP address) — concluding tunneling exists when attributes fail the norms.
• Claim(s) potentially implicated:
  • The conceptual "detect malicious tunneling" premise of the independent claims; the "traffic data" element (connection timing, volume, frequency).
  • § 102 assessment: This is the most on-point prior art to the tunneling-detection concept, but it does not teach the signature log-correlation step (the same IP as VPN client IP and outbound remote IP) or user-data-based risk scoring. It would not anticipate the independent claims on its own; it is a strong § 103 primary reference.

3.3 US 8,615,605 B2 — Automatic identification of travel and non-travel network addresses

• Assignee: Microsoft Corporation
• Dates: priority 2010-10-22; granted 2013-12-24.
• Description: Automatically classifies a network address as a "travel" vs. "non-travel" address (e.g., based on historical usage/geolocation).
• Claim(s) potentially implicated:
  • The geographic-location / "geographic mismatch" dependent features and the user-data "user geographic location" element.
  • § 102 assessment: Not an anticipation of any independent claim; relevant only as a § 103 secondary reference to the location/geography-based risk factor.

3.4 US 2014/0181968 A1 — Monitoring Operational Activities In Networks And Detecting Potential Network Intrusions And Misuses

• Assignee: AT&T Intellectual Property I, L.P.
• Dates: priority 2012-12-20; published 2014-06-26.
• Description: Monitors operational activities/logs across a network to detect potential intrusions and misuse.
• Claim(s) potentially implicated:
  • The general monitoring-of-network-logs and intrusion-detection/alerting context of all three independent claims.
  • § 102 assessment: Does not disclose the specific dual-log IP correlation or the user-data risk-score/alert combination; § 103 material at most.

3.5 US 8,788,405 B1 — Generating data clusters with customizable analysis strategies

• Assignee: Palantir Technologies, Inc.
• Dates: filed 2013-03-15; granted 2014-07-22.
• Description: Cluster-generation with customizable analysis strategies (seed-based clustering). This is the reference expressly incorporated by reference in the '046 specification as "U.S. Pat. No. 8,788,405" for the clustering process (designating the client IP as a seed to gather additional traffic/user data).
• Claim(s) potentially implicated:
  • The "determine traffic data / user data" gathering steps in the independent claims, via the seed-and-cluster technique.
  • § 102 assessment: Same-family/related Palantir disclosure, incorporated by reference, not an anticipatory prior-art patent against the independent claims.

4. Additional references appearing in the USPTO record

The uspto.report grant record for 10,609,046 lists a much longer "References Cited" table of U.S. patents and U.S. pre-grant publications (running from US 8,954,410 (2015) through US 10,229,153 (2019), and publication numbers from 2001/0051949 through at least 2004/0250124 and beyond), including numerous Palantir patents in the same portfolio (e.g., US 9,419,992 and US 9,930,055 — the earlier "Unwanted tunneling alert system" grants; US 9,537,880; US 9,628,500, etc.).

I am reporting this as what the aggregator displays, with an explicit caveat: I could not independently verify each item against the front-page of the granted patent, and several entries appear to be same-family/related Palantir patents (which are normally listed under a related-applications heading rather than as prior art). I therefore do not fabricate descriptions or § 102 mappings for entries I could not confirm. If a certified list is needed, the "References Cited" on the first page of US 10,609,046 B2, or the patent's IDS/PAIR file wrapper, should be consulted directly.

I also note the forward citation US 10,735,448 B2 (Palantir, "Network anomaly detection"), which cites the '046 family — a citing (not cited) document and thus not prior art.

5. Net § 102 assessment

• No single cited reference anticipates the independent system, method, or CRM claim. None of the five citations discloses the pivotal limitation — identifying a first IP address that appears as a client IP in the VPN log and as a remote (destination) IP in the outbound data-connection log — let alone the full chain of user data → traffic data → risk score → threshold alert.
• Closest prior art: US 2006/0031928 A1 (Conley) for the tunneling-detection concept, and US 8,448,247 B2 (Global Dataguard) for the score/threshold/alert and feedback elements. Together (optionally with US 8,615,605 and US 2014/0181968 for the geographic and monitoring aspects) they form a plausible § 103 obviousness combination against the broader claims, but not a § 102 anticipation of the independent claims.
• § 102-specific mapping summary:

6. Sources and limitations

• Google Patents US 10,609,046 B2 — https://patents.google.com/patent/[US10609046B2](/patent/US10609046B2)/en
• Google Patents family/citation record (EP 3,349,414 A1 and US 9,419,992) — patent citations table — https://patents.google.com/patent/EP3349414A1/en ; https://patents.google.com/patent/US9419992
• uspto.report grant record — https://uspto.report/patent/grant/10,609,046
• US 8,448,247 B2 — https://patents.google.com/patent/US8448247 ; https://patents.justia.com/patent/[8448247](/patent/8448247)
• US 2006/0031928 A1 — https://patents.google.com/patent/US20060031928A1 ; https://patents.justia.com/patent/20060031928
• US 8,615,605 B2 — "Automatic identification of travel and non-travel network addresses" (Microsoft)
• US 2014/0181968 A1 — "Monitoring Operational Activities In Networks And Detecting Potential Network Intrusions And Misuses" (AT&T)
• US 8,788,405 B1 — "Generating data clusters with customizable analysis strategies" (Palantir)

Limitations: (i) I was unable to pull the verbatim front-page "References Cited" and non-patent-literature list of US 10,609,046; the five patent citations above are those reported by Google Patents for this family, and the longer uspto.report list is reported as-is without fabrication. (ii) The exact claim numbers of the '046 patent are not reproduced in the retrievable data, so mappings are to the three independent claim groups (system/method/CRM) and to the dependent features described in the specification. (iii) Per the operating rule, the 2014-08-12 vs. 2014-08-13 priority-date discrepancy is left uncorrected. A definitive § 102/§ 103 analysis would require the granted claim set and the examiner's cited-art forms, which should be pulled from the USPTO PatentCenter/PAIR file wrapper.

I'll ground this analysis in the actual prior-art references cited on this patent's page, and verify the most relevant ones before reasoning about combinations.

Good — the Ward reference is a Palantir GUI patent, not a security reference. Let me verify the tunneling-detection prior art that appears in this patent family's citation records.

Obviousness Analysis — U.S. Patent No. 10,609,046 B2

"Unwanted tunneling alert system" (Palantir Technologies Inc.)

Under 35 U.S.C. § 103 / AIA §§ 102–103 | Analysis date per prompt: April 26, 2026

Scope note carried over from the prior sections. This builds on the verification-only report and litigation summary already generated. I do not repeat the bibliographic findings here. Two cross-reference flags from those sections remain live and are material to the date analysis below: (i) the 2014-08-12 vs. 2014-08-13 priority-date discrepancy appears in the record and is not auto-corrected; (ii) the previously-generated summary could not verify the exact independent-claim numbering for the '046 (23 claims; parent publication had independents at 1/8/15). Everything below is written against the substance of the three disclosed aspects, not against a verified claim set.

1. Governing standard and the threshold date problem

Legal standard. Obviousness is a legal conclusion resting on the Graham v. John Deere factors: (1) scope and content of the prior art; (2) differences between the prior art and the claims; (3) level of ordinary skill; (4) secondary considerations. Under KSR Int'l v. Teleflex, a combination is obvious when prior-art elements are combined "according to known methods to yield predictable results," when a known technique is applied to improve a similar device, or where the improvement is an "obvious to try" design choice from a finite number of identified, predictable solutions.

Effective filing date — and why it matters here. The '046 claims the chain 62/036,999 (Aug. 13, 2014) → 14/823,935 (Aug. 11, 2015) → 15/228,297 → 15/891,873 (Feb. 8, 2018). AIA §§ 102/103 govern.

Two consequences:

1. Under Dynamic Drinkware, each claim gets the Aug. 13, 2014 provisional date only if the provisional supports that claim. Any claim limitation not supported by the provisional falls back to Aug. 11, 2015. This creates a bifurcated art window, and — importantly — it determines whether at least one of the cited references can be prior art at all.
2. Ward (US 2016/0062555 A1) — date problem I want to flag explicitly. The search confirms US 2016/0062555 A1 is "System for providing dynamic linked panels in user interface" (Ward et al., Palantir), and the corresponding US 9,454,281 B2 record shows it was filed Aug. 31, 2015, published Mar. 3, 2016, and claims provisional 62/045,488 filed September 3, 2014. That is after Aug. 13, 2014. So Ward is not § 102(a)(1) art, and it is not § 102(a)(2) art either — unless the challenged claim loses the provisional date and falls back to Aug. 11, 2015... in which case Ward (effectively filed Sept. 3, 2014) becomes § 102(a)(2) prior art. This is a claim-by-claim determination. Ward is also, on its face, a GUI/query-panel patent, not a security reference — so if it is cited, it is cited for the "alert displayed in a GUI" limitation, not for tunneling detection.

Verification note: the fetched page text I was given does not include the "Patent Citations / References Cited" table — only the "Prior art keywords" fields (indication, alert, user, address, network) and "Prior art date 2014-08-13." I therefore anchor the analysis on (a) the references listed in the previously-generated summary as being of record, (b) references I verified via search as cited in this patent family (notably on sibling EP 3 349 414 A1, "Malicious tunneling handling system" — https://patents.google.com/patent/EP3349414A1/en), and (c) references I independently verified exist in the same technical space. Each is labeled below.

2. What each reference actually discloses (scope and content)

3. The primary combination

Conley (US 2006/0031928 A1) + Sprague (US 8,788,405 B1) + AT&T (US 2014/0181968 A1), optionally + Ward (US 2016/0062555 A1)

Mapping to independent claim 1 (system claim) as recited in the patent's own Summary:

4. Why a POSITA would have been motivated to combine these (the § 103 rationale)

(1) The problem itself is handed to the POSITA by Conley. Conley's background does not merely describe tunneling generally — it describes the '046's specific scenario: an internal machine opens an outbound connection so an external party tunnels back in, and it labels that pattern as "very common with users wanting to access their office machine after hours from their home network." A POSITA starting in 2013–2014 with the enterprise-network-security problem the '046 poses would find the reference that names the exact attack pattern. That is motivation to start with Conley, satisfying the "known problem" prong.

(2) Conley's method has a known, self-evident weakness that supplies the motivation to combine. Conley is a packet-attribute/norm-deviation detector. It flags "potential tunneling activity… if it fails to conform to any one or more" of five norms. That design is intrinsically high-false-positive: legitimate large transfers, long SSH admin sessions, or ordinary high-connection-frequency workloads violate the norms, while a well-shaped tunnel (e.g., SSH-over-HTTP on port 80/443, precisely the evasion the '046 describes in its Background) is built to look norm-conforming. The well-documented field-wide false-positive problem is the classic "known technique ready for improvement" rationale of KSR/MPEP 2143(D): a POSITA motivated to reduce false positives would look for additional, independent evidence of tunneling beyond packet shape. The '046's cross-log overlap is exactly such independent evidence.

(3) Sprague supplies the "how" and, critically, the patent itself concedes the technique. The '046's specification incorporates US 8,788,405 by reference and describes designating the client IP address as a seed and expanding to traffic and user information via a clustering process. An express incorporation-by-reference plus an instruction to use the technique is about as strong a "known technique" showing as exists — it is effectively an admission that a POSITA had the tool and would apply it. Sprague's data-binding/search-protocol machinery is address-agnostic; applying it with the client IP address as the key (which the '046 itself says to do) is a predictable use yielding predictable results.

(4) The correlation itself is routine data fusion on a shared key. Iterating records against one another across logs on a common field is elementary. The '046 trades on this: the VPN log and the proxy log are both enterprise-owned, already-collected, unencrypted-at-rest artifacts. The skilled person needing to correlate them needs no new capability — only the recognition that the same address appearing in both is probative. KSR expressly sanctions combinations where "a person of ordinary skill can implement a predictable variation."

(5) AT&T / US 2014/0181968 corroborates the monitoring-to-alert pipeline. Even taking it at title level, it establishes that operational-activity monitoring feeding intrusion/misuse detection was a known enterprise framework into which a tunneling-specific detector would be dropped.

(6) Ward supplies only the presentation layer. If the GUI limitation is reached, the motivation is the universal one: presenting detection results to the human who must act on them. The '046 itself cites Attorney Docket No. PALAN.235A1P5 for alert generation/display — an admission that the alerting/UI layer is known art.

5. Where obviousness is weakest — and the counter-arguments a patentee would press

I want to be candid rather than build a one-sided case.

(A) The gating step (c) is the crux, and no single reference shows it. The specific predicate — the same address is a VPN client address in log #1 and a destination/remote address in log #2 — is the point of novelty. Conley monitors one vantage point and compares to norms; it does not cross-reference two enterprise logs. A patentee will argue that:

• Conley's detector is designed for the packet/transport layer, not for identity/log correlation, and the reference's own framing ("no specific techniques known to the inventor") arguably teaches away from log-joining;
• the insight that the return address equals a current VPN client address specifically captures the reverse/nested-tunnel case that Conley treats as one example among several and does not isolate; and
• the prior art's decryption-based approach (US 8,856,910) teaches decrypt-and-inspect, which is a different solution direction — arguably a teaching away from a non-decrypting, log-correlation solution.

My assessment: the strongest non-obviousness argument is "no reference taught or suggested the specific log-overlap predicate" — i.e., a § 103 argument aimed at the gate, not at the scoring. The response is that the overlap is a predictable application of a known data-correlation technique to two known data sources to solve a known problem, which KSR treats as obvious; the "teaching away" point is weak because Conley never disparages log correlation, and US 8,856,910's MITM approach coexists with (and motivated the search for) non-decrypting alternatives — certificate pinning, scale, and privacy concerns all supply the motivation to avoid MITM.

(B) Secondary considerations are the real battleground. I found no evidence of commercial success, long-felt need, industry praise, or failure of others tied to the '046 with a demonstrated nexus. Absent that, the Graham factor (4) does not rescue the claims. Any obviousness defense should, however, probe whether Palantir's actual product implementation produced evidence of nexus.

(C) Claim-drafting fragility helps the challenger. The independent claims are drafted at a high level of generality ("determine user data"; "determine traffic data"; "generate a risk score… at least partly indicative of a likelihood"). Broad functional recitations of this kind are easier to meet with prior art than a narrow, structural claim would be — and they also invite § 112(b) indefiniteness attacks on "risk score" and "at least partly indicative."

6. Obviousness disposition of the dependent claims

Alternative secondary combination (independent of Conley): US 8,856,910 + US 8,615,605 + Ward — i.e., decryption-based SSH-tunnel detection + travel/non-travel address classification + an alert-UI reference. This covers (b)–(g) but is weaker on limitation (c), because decryption-based detection does not require log joining. It is a useful backup but not the primary theory.

7. Confidence, caveats, and what I could not verify

High confidence:

• The AIA § 102/103 framework and the Dynamic Drinkware threshold-date issue apply and are outcome-determinative for the Ward reference.
• Conley US 2006/0031928 A1 is squarely on point for the tunneling-threat narrative and for the traffic-data limitations (source IP, destination IP, port, protocol, timing, volume). This is a verified disclosure, retrieved directly.
• US 8,788,405 is available as § 102(a)(1) art (issued July 22, 2014, before the Aug. 13, 2014 date) and is incorporated by reference by the '046 itself — the strongest single motivation showing in the record.
• US 2016/0062555 (Ward) is a GUI/query-panel patent, not a tunneling reference, and its § 102 status turns on the claim's effective date.

Medium confidence / flagged:

• I did not verify the contents of US 2014/0181968 A1 or US 8,615,605 B2 — my search steps were exhausted at that point. Both are verified only as cited references on the sibling EP 3 349 414 A1 record. My use of them is title-and-citation-derived and must be confirmed against the actual documents before being relied on in any filing.
• US 8,856,910 B2 / US 2015/0058916 A1 is verified to exist and to disclose MITM decryption of SSH tunnels, but I could not confirm it is of record in the '046, and I could not verify its filing date for § 102(a)(2) purposes.
• The exact independent-claim numbering of the '046 (23 claims) remains unverified — the element mapping in § 3 reflects the substance recited in the patent's Summary, not the issued claim text.
• The 2014-08-12 vs. 2014-08-13 priority discrepancy remains unreconciled; a one-day shift does not change any outcome above (no reference sits on that boundary), so I did not resolve it.

One thing I want to state plainly rather than paper over: I cannot responsibly render a bottom-line "claims are/are not obvious" conclusion. Obviousness here turns on (i) the exact issued claim text, (ii) the actual References Cited list from the file wrapper (the fetched page did not contain it), and (iii) whether the challenged claims retain the Aug. 13, 2014 provisional date — which single question flips Ward in or out of the art. My honest assessment of the strongest § 103 theory is Conley + US 8,788,405 + US 8,615,605 (+ AT&T 2014/0181968 for the alert framework), with Ward reserved for the GUI limitations and available only if the provisional date is lost; and that the hardest limitation to meet is the cross-log IP-overlap predicate, which no single reference shows and which would have to be established as a predictable application of routine data correlation.