Confidential · Internal · Measurable AI

ScreenLake IP auction: opportunity analysis & bidding strategy

A working read of the qualified-bidder data room, the seller's interactive deck, and ScreenLake's footprint set against our own operating scale. The numbers are visualised below — hover any chart. Bottom line up front, valuation and a recommended bid at the end.

Analysis 21 May 2026 Lots SDK + patents · Digitox app Bidding closes 4 June 2026 · 14 days

Contents

  1. 01Recommendation & bottom line
  2. 02What is actually for sale
  3. 03Strategic fit & scale
  4. 04The Artemis SDK
  5. 05The three US patents
  6. 06Digitox: the app & the panel
  7. 07What the technology produces
  8. 08Valuation & bidding strategy
  9. 09Risks & red flags
  10. 10Action plan
01 — Bottom line

Recommendation: a patent-defence bid, or none at all


ScreenLake is liquidating a passive-metering SDK and three patent applications. RewardBox already does what the SDK does — and, for our business, does it better — so this is not a capability acquisition. It narrows to one real question: are the patents worth owning defensively?

The verdict

This is a patent-defence decision. Skip Lot B. Let the IP opinion set the bid on Lot A.

RewardBox already reads on-screen text, runs parsers that normalise full transaction journeys, and automates history capture. For our business it is, if anything, ahead of Artemis — so this is not a deal that upgrades RewardBox's capability, and the SDK code is not the prize.

That leaves the three patent applications as the only reason to engage — and even that is now in doubt. The claims describe on-device term-collection matching; RewardBox is a structured screen parser, a technically different method the claims may not reach. IP counsel's job is now sharp and narrow: do term-matching claims read onto a parser-based system? If yes, a disciplined defensive bid is warranted. If no, there is little here for us.

The real asset

Not the SDK — RewardBox already reads screens and extracts transaction journeys. It is the three patents, which may read onto RewardBox as it exists and would be dangerous in a rival's hands.

Why to be disciplined

No customers, no revenue, an "as-is" liquidation. The patents are applications, not grants. The Digitox panel is down ~50% in 14 months and is a rounding error against our own scale.

What to do now

Engage IP counsel this week. Access docs.screenlake.com and the Play Console. Set per-lot ceilings. Decide if the patents alone justify a defensive bid.

02 — The opportunity

What is actually for sale


ScreenLake Inc. (Delaware; founder Daniel Muise, PhD) is a passive smartphone-metering company being wound down. It is auctioning two separate IP assets through airauctioneer.com/screenlake, anonymous bidding, closing 4 June 2026. Explicitly an asset sale — the seller confirms "no active customers nor end-funnel prospects."

Lot A — the core technology

Artemis SDK + 3 US patents pending

A closed-source passive-metering SDK for Android ("Screenlake Glass," internally "Artemis"). It uses the Android Accessibility API to scan on-screen text every 3 seconds, detect ~13,000 tracked brands and terms, and run on-device NLP — sentiment, ad detection, purchase detection — then transmit anonymised, pre-aggregated data. Bundled with three pending US patent applications and the cloud backend.

Lot B — the distribution vehicle

Digitox Android app + audience

A working screen-time app on Google Play (phosphorus.app.usage.screen.time), 1M+ historic installs, ~52k active installs, ~24k monthly users, concentrated in Turkey, Germany and France. ScreenLake bought it in 2023 as a panel vehicle. The current build has data-collection code removed ahead of sale.

The lots are independent — value and bid them separately.

Lot A is, for us, a patents question; Lot B is a panel question. They share nothing in our decision, so treat them as two separate bids — and, as the rest of this analysis argues, Lot B barely warrants one.

03 — Strategic fit

The fit, and the scale that reframes it


Their panel is a rounding error against ours

The most important comparison in this whole analysis is one of scale. ScreenLake spent a one-time app purchase plus ~$91.5k of marketing to assemble its panel. At its all-time peak it reached 16,663 monthly accessibility-data uploaders; today it is ~8,100. Our own MDT ecosystem, by contrast, holds millions of active, consented data-sharing users.

3.30M
Our active panel users — Week 124, May 2026 · internal Insight Dashboard
vs
8,135
ScreenLake — total accessibility-data uploaders, Mar 2026 · data room
Our data-sharing panel — active vs. accumulated
Active opt-in users (the panel metric that matters) and accumulated registered, Jan 2024 – Apr 2026. Hover for figures.

The implication is direct. Buying ScreenLake's panel would add ~0.25% to our active base — it is immaterial. So Lot B can be set aside on scale grounds alone, and the decision reduces to Lot A: is ScreenLake's technology, or its patents, worth owning? The trajectories make the panel point final too — our active panel has grown ~24% over two years and is stable week to week, while ScreenLake's accessibility panel has shed roughly half its uploaders since early 2025.

RewardBox vs. Artemis: different instruments — and ours fits our business better

RewardBox is not a usage timer. It already reads actual on-screen text; it runs purpose-built parsers that normalise complete transaction journeys — an Uber trip from ride search to request to on-ride to drop-off and rating; and it ships automation that drives apps to harvest history (open Uber, walk trip history, capture every trip; the same for Amazon orders). Its app coverage is capped not by capability but by a backend-config choice: because it uploads raw data streams to the cloud, scanning every app is a data-volume problem, not an engineering one.

Artemis is built on the opposite philosophy. It scans every app but shallowly — recording flat "encounter" rows (a brand or term appeared, with a sentiment score and an ad flag), processed on-device so only compact tabular data is uploaded. It has no transaction-journey normalisation and no automation.

So the two are different instruments, not better and worse. RewardBox is narrow and deep — structured transaction journeys, automation, parsers tuned to our verticals: our business. Artemis is broad and shallow — brand exposure and share-of-attention across everything: ScreenLake's business. For what Measurable sells, RewardBox is the more advanced of the two. The acquisition does not "upgrade" RewardBox.

It does not solve our actual hard problem either. Broad coverage, for us, means a screen parser built per app and quality training samples collected per app from paid real users — the slow, costly work behind the structured trip data we deliver today. ScreenLake never solved that; they avoided it by going shallow. There is no parser library inside Artemis to inherit. The difficulty is real — but it is also our moat: competitors hit the same wall.

The one place Artemis's design speaks to a real RewardBox limit.

RewardBox's app coverage is capped by upload volume — it ships raw streams to the cloud. Artemis's edge-first architecture (process on device, upload only compact results) is exactly the design that removes that cap. That is the single genuinely relevant technical idea in the SDK. But it is an architecture, not drop-in code: Artemis's C++ engine does dictionary term-matching, not RewardBox's journey parsing, so our team would re-architect rather than reuse. It validates an approach more than it delivers one.

A separate-product option — not a RewardBox upgrade

There is one way Artemis's broad-capture design could earn its keep: as the basis of a new product. If Measurable ever wants a distinct brand-exposure / ad-measurement line — share of voice, brand awareness, the social-listening-style output ScreenLake's deck pitched — Artemis's broad capture, 14.7k-term dictionary and on-device sentiment are a head start on it, and it would sit above transactions for the same investor and platform buyers. But that is a decision to enter a new product category, separate from anything RewardBox needs. Treat it as optionality, not core deal rationale.

Markets: the Digitox panel is in the wrong countries — bar one

With our own panel numbers in hand, the geographic fit can be made exact — measured, as it should be, on active users. Our active panel is overwhelmingly emerging-markets: led by Indonesia, the Philippines and India, then Mexico, Brazil and across Southeast Asia, Latin America and MENA. ScreenLake's footprint, through Digitox, is Turkey, Germany, France, then the US and UK.

Our active panel by country — top 16 of 240
Active users, Week 124. Turkey is the one market that overlaps Digitox. Hover for figures.

Set side by side, the two panels barely meet. Across Digitox's five markets, only Turkey is material to us:

Digitox marketDigitox rankOur active panelOur rankOverlap
Turkey#1109,190#8Strong
Germany#28,971#32Weak
France#310,377#30Weak
United States#441,271#19Modest
United Kingdom#58,739#34Weak

Turkey is the single strong overlap — Digitox's largest market and our eighth by active users. Germany, France and the UK are immaterial to us; the US is modest. And Brazil — our #5 active market, and where RewardBox already operates — gets nothing from Digitox. The conclusion compounds the scale point: the Digitox panel is close to orthogonal to ours, while the SDK is geography-agnostic. Deployed into our apps, Artemis would generate screen-content data exactly where our active users already are — Indonesia, the Philippines, India, Brazil.

The fit, scored

Patent-defence value
The only real rationale — but uncertain: RewardBox is a parser, not a term-matcher, so the claims may not even reach it.
SDK as a RewardBox upgrade
Minimal. RewardBox already reads screens and extracts transaction journeys — it is ahead for our use case.
Edge-compute architecture
Addresses RewardBox's real app-coverage cap — but a validated approach, not reusable code.
New brand-measurement product
Optionality only, if we choose to enter that line. Dictionary is thin in our verticals.
Digitox panel — audience value
~0.25% of our base, decaying, wrong countries. Negligible.
What this does not solve: retention.

ScreenLake's panels decayed ~50% in 14 months once marketing stopped. The SDK is excellent; durable engagement is a separate, unsolved problem — for them and, candidly, the issue behind RewardBox's ~5k active contributors. Acquiring the engine does not fix churn. Budget separately for incentive design.

04 — Lot A, part 1

The Artemis SDK


A mature, well-architected production codebase, not a prototype. The data room includes an architecture document, a software bill of materials, battery-test data and a link to live developer documentation.

117,377
Lines in the native C++ analysis library
~13,000
Tracked brands & terms in the on-device dictionary
3 sec
On-screen text scan interval
~2.4%
Measured battery overhead vs. normal use

How it works

Battery cost is genuinely low

The data room's battery tests across seven devices put the SDK's overhead at roughly one percentage point of battery per day, about 2.4% over normal drain — heaviest in browser-heavy use, lightest in social. For an accessibility app, where battery complaints drive uninstalls, this is a real asset.

SDK battery overhead by usage category
Extra drain attributable to the SDK, as a share over normal use (US test panel, v_21).

Strengths

  • Clean component architecture; modern Gradle/Kotlin/Room stack
  • 375+ dependencies, all runtime licenses permissive — no copyleft contamination
  • Google Play App Signing; per-device tenant isolation; AES-256 license encryption
  • Cloud backend ("Olympia") documented and CI/CD-automated

Gaps (per ScreenLake's own docs)

  • Only 22 test files; no load / stress / battery / E2E / security testing
  • No APM, centralised logging, alerting or distributed tracing
  • Infrastructure manually provisioned — no Terraform / CloudFormation
  • Last-mile pipeline uses monthly manual SQL steps; "not expected to transfer"
Closed-source — verify the transfer scope.

The data room shares documentation, not code. The deal must explicitly transfer the actual repositories, the 117k-line C++ engine, the dictionary and taxonomy data, build and signing keys, the docs site — and clarify whether the "Olympia" backend is in or out.

05 — Lot A, part 2

The three US patent applications


Three US non-provisional applications filed September 2024 through patent counsel. They share a common specification family and read directly onto the SDK's method. Powers of attorney and declarations are executed; non-publication requests were filed, so they are not yet public.

ReferenceTitleFocus of claimsClaims
SCLK.P001Display Screen Content AnalyticsThe core on-device method: store a term collection, transcribe screen content, detect matches, selectively record matched terms and context.20
SCLK.P001-2Display Screen Content AnalysisContextual inference: sentiment scoring, ad / commercial-content detection, threshold-triggered uploads, encrypted anonymised transmission.21
SCLK.P001-3Display Screen Content Analysis for Determining Term EncountersThe server side: distributing term sets to many devices, receiving encounter reports, maintaining an aggregate store with proximity / sequence analysis.20

Defensive value

RewardBox already performs on-device accessibility-based collection. These applications, if granted, could read onto our own method. Owning them protects RewardBox and removes a litigation lever a competitor could hold.

Offensive / blocking value

In a competitor's or a non-practising entity's hands, they become a tool to tax or block on-screen metering players. A liquidation IP auction's buyer pool often includes exactly such parties.

Critical caveat: applications, not granted patents — and they may not even reach RewardBox.

Filed but not examined. Value depends on grant likelihood, surviving claim breadth, and prior art — mobile passive metering is a crowded field (Nielsen, RealityMine, Verto, comScore and others). The independent claims are broadly worded: attractive scope, but more exposed to prior-art rejection. A second question matters just as much: the claims describe term-collection matching, while RewardBox works by structured screen parsing — counsel must say whether the former reads onto the latter. If it does not, the defensive rationale falls away. We cannot price this lot without that opinion; it is the gating due-diligence item.

06 — Lot B

Digitox: the app and the panel


Digitox is a genuine, years-old screen-time app. ScreenLake bought it in December 2023 from its original developer (Cihan Turkay, Turkey) for US$55,000, then spent ~$91.5k on Google Ads in 2024 to grow it. Both numbers are useful valuation anchors.

~52,000
Active installs, May 2026 (was ~145k peak, Aug 2024)
~24,000
Monthly active users (was ~91k peak)
~3,100
Daily active users — down from ~10k
$55,000
Price ScreenLake paid for the app, Dec 2023

The audience: a two-year decline

The Play Store audience peaked in August 2024 on a paid-marketing burst, then slid steadily once marketing stopped. Installs, monthly and daily actives all tell the same story.

Digitox Play Store audience — May 2024 to May 2026
Click a series to toggle it. Hover for monthly values.

The marketing burst that did not stick

One detail from the ad data is worth flagging. In August 2024 ScreenLake bought 89,564 installs for $13,441 — about $0.15 each, far below the ~$0.65 blended cost of its other campaigns. That single cheap burst is the spike in the chart above. It inflated the install count but washed out fast: monthly actives gave back most of the gain within two months. A reminder that headline install counts on this app were partly bought cheap and low-intent.

2024 Google Ads — installs per month
Total spend ~$91.5k for ~141k installs. Hover for spend and cost-per-install.

The data panel, and where it lives

Of the install base, a smaller cohort actually uploads data. That panel — the part that matters — peaked around the December 2024 marketing afterglow and has fallen ~50% since. The accessibility panel (the on-screen-content one) is the smaller and faster-shrinking of the two.

Monthly data uploaders
App-usage panel vs. accessibility panel.
Accessibility panel by country
Mar 2026. Turkey leads; only Turkey overlaps our markets.
Unconfirmed but material: a Play Store "Unpublished" event.

The Play Console activity log records the app set to UNPUBLISHED on 20 November 2025. It is unclear whether this was temporary, is current, or reflects a Google policy action. An unpublished app cannot gain new installs. Confirming the current, live publish status is the first question to ask — it materially changes Lot B's value.

Competitive signal from the same log.

On 20 November 2025, Play Console access was granted to two addresses at mobilesoft.eu — MobileSoft, developer of the screen-time app AppBlock — consistent with another strategic party doing due diligence. Bidding is anonymous; assume we are not the only serious bidder.

07 — The output

What the technology produces


The data room sample shows exactly what the SDK emits. Two datasets: a row-per-encounter brand/topic log, and a row-per-app daily usage log. The encounter sample is 10,000 rows — 6,915 distinct encounters from a single, politically-engaged US panelist over just three days in November 2025. That density (~2,300 encounters/day for one user) is itself a data point: the capture is continuous and rich.

The dictionary already spans our verticals — but ride-hailing is thin

The V_22 term library holds 14,724 terms across 63 industries. It already covers the consumer economy broadly, including most of what we track. The gap is specific and fixable: ride-hailing and delivery dictionaries are sparse. This is the concrete shape of the seller's "minor tweaks" claim — the framework and most verticals are there; the rideshare and delivery term sets need building out.

V_22 dictionary — terms per industry
Selected of 63 industries. Highlighted = directly relevant to our verticals. Hover for counts.

What an encounter feed looks like in the wild

In the sample, encounters were captured across the user's whole app surface — browser, news, social, messaging. Each carries a sentiment score (sample mean 0.70, compressed by design toward 0.6–0.8), an ad flag (2.5% of rows), foreground app, surrounding topic and timestamp. The cross-app spread below is the point: no single-platform API or scraper sees this.

Where encounters were captured — encounters by foreground app
10k-row sample, one US panelist, 3 days. Hover for counts.

It has already been turned into product

ScreenLake's deck shows finished output, not concepts: a GLP-1 drug share-of-voice study on 1,000 representative US adults; political impression time-trends for researchers at Northwestern and NORC; brand-mention tracking inside the ChatGPT app; and a self-serve "Brand Information Dashboard" with Daily Audience, Daily Impressions and a "Brand Love Score," competitor benchmarking and CSV/PDF export. The productisation risk is low — the harder question is durable panel supply, which is ours to solve.

Two upside angles worth weight.

Brand tracking inside AI chat apps is a scarce, forward-looking alt-data stream few vendors can offer — directly sellable to our investor and platform clients. And the dictionary's 684-term Stocks category maps onto our hedge-fund customers. Neither is visible in the data-room spreadsheets alone.

08 — Valuation

Valuation & bidding strategy


An indicative framework, not an appraisal — built from data-room evidence and standard methods (comparable transactions, cost-to-replicate, strategic value). Refine once IP counsel has opined on the patents. All amounts USD.

Lot B — Digitox

ScreenLake paid $55k in December 2023 for a healthier app, then spent ~$91.5k on marketing. Today it has no revenue and a panel that, against our 3.3M active users, is strategically immaterial as a panel. For us, Lot B's value is narrow: an aged, accessibility-approved, Turkey-heavy Play Store listing — useful as a vehicle or template, not as an audience. On pure financials a non-revenue utility app at this scale is worth roughly $15k–$50k.

Lot A — Artemis SDK + 3 patent applications

Value to Measurable is not a build-vs-buy calculation. We would not rebuild Artemis — we built RewardBox instead, and for our business it is the better-fit system. Lot A's worth to us is therefore almost entirely the patents as defensive insurance. But that case is itself conditional: RewardBox is a structured parser and the claims describe term-matching, so whether they reach our method at all is genuinely uncertain. The SDK code, dictionary and edge-compute architecture are a modest bonus, not the basis of a bid. One input sets the number — the IP counsel opinion.

Lot A — SDK + patents
A patent-defence bid
Value driverThe patents
If patents strong & likely to grant$90k–180k
If patents weak / unlikely≤$40k, or walk
Walk-away ceiling*set by IP opinion
Lot B — Digitox
Optional / opportunistic
Financial value (standalone)$15k–50k
Strategic value to uslow
Suggested target$20k–40k
Walk-away ceiling~$60k

*There is no fixed Lot A ceiling until IP counsel reports. Strong, broad, likely-to-grant claims that read onto RewardBox justify a disciplined six-figure defensive bid — the cost of a rival holding them is higher. Weak claims mean there is little here for us: bid token money or walk. The SDK code itself does not move this number much, because we would not have built it.

Bidding principles

  1. Bid the lots separately. Lot A is a conditional patents bid; Lot B is near-irrelevant. Never let competition for one drag our price on the other.
  2. Set ceilings before bidding opens and hold them. Anonymous auctions reward pre-commitment and punish escalation. Decide the numbers cold, in writing, this month.
  3. Value Lot A as insurance, full stop. The whole case rests on the cost of not owning patents that may read onto RewardBox if a competitor or NPE wins them.
  4. Let Digitox go. At our scale its panel is immaterial; above a token price there is no reason to hold it.
All-in guidance.

There is no all-in number until the IP opinion lands. If the patents are strong, a combined bid in the order of $90k–$200k — almost all of it Lot A, as patent insurance — is disciplined. If they are weak, the right spend is close to zero. Confirm the auction reserve, minimum increments and any buyer's premium on airauctioneer.com before finalising.

09 — Risks

Risks & red flags


High
Accessibility-permission regulatory risk

Google Play keeps tightening use of the Accessibility API for non-accessibility purposes. Both Digitox and RewardBox depend on it. An existential, sector-wide risk — the acquisition does not reduce it.

High
Patents are unexamined applications

No grant is guaranteed; claim scope is unknown; the field has substantial prior art. Without an IP opinion, Lot A's headline value is unverified.

High
Decaying panel, no customers, no revenue

Both ScreenLake panels are down ~50% in 14 months; zero active customers or pipeline. Whatever we buy here, it is not cash flow.

Med
"As-is" liquidation sale — limited recourse

Expect assets conveyed as-is with minimal warranties. Verify title, liens and secured-creditor claims independently.

Med
Old SDK installs still "phoning home"

ScreenLake notes out-of-date APKs may still attempt uploads (rejected by a soon-to-sunset AWS endpoint). Clarify residual legal exposure and whether it transfers.

Med
GDPR exposure on the EU-heavy panel

Digitox's panel is concentrated in Germany, France and Turkey. Acquiring it may make us a data controller for EU subjects. Confirm consent records and lawful basis.

Med
Competing strategic bidders

The activity log shows MobileSoft (AppBlock) was given Digitox console access. Expect at least one informed competitor.

Low
Engineering hardening cost

The SDK needs test coverage, observability and infrastructure-as-code before panel-scale operation — a known, budgetable cost.

10 — Action plan

Due diligence & timeline


Fourteen days to bid close. Tight but workable if IP counsel is engaged immediately. Items 1–3 are gating.

Due-diligence checklist

01Patent FTO & patentability opinion. IP counsel assesses grant likelihood, claim breadth vs. prior art, and freedom-to-operate for RewardBox. The single most important action.
02Confirm Digitox's current Play Store status. Live, in limited rollout, or unpublished? If de-listed, learn exactly why.
03Confirm patent ownership chain & liens. Verify ScreenLake owns all three applications, inventor assignments recorded, no secured-creditor claim.
04Pin down the SDK transfer scope. Repositories, the C++ engine, dictionary data, build & signing keys, docs site — and whether the "Olympia" backend is included.
05Review the developer documentation. Access docs.screenlake.com and scope integration effort into RewardBox / our apps.
06Request Play Console read access. Email info@screenlake.com to validate the data-room spreadsheets.
07Verify Digitox clean title back to 2023. Confirm the original purchase agreement's IP assignment fully completed.
08Confirm auction mechanics. Reserve prices, minimum increments, buyer's premium, payment and transfer terms.

Timeline to 4 June

This week — 21–25 May
Engage IP counsel & open all data access.

Brief patent counsel for an expedited FTO read. In parallel, request Play Console access, log into docs.screenlake.com, start engineering's documentation review.

26–30 May
Complete gating due diligence.

Receive the IP opinion. Confirm Digitox publish status and patent ownership. Engineering returns an integration-effort and hardening-cost estimate.

31 May – 2 June
Set bid strategy & ceilings, in writing.

Finalise per-lot target and walk-away numbers. Decide the Lot B participate/skip question. Internal sign-off on budget and the decision-maker at close.

4 June — bidding closes
Execute. Hold the ceilings.

Bid Lot A as the priority. Treat Lot B as opportunistic and walk above the ceiling.

Net: this is a patent decision — and the bar to bid has risen.

We are not buying a capability: RewardBox already captures the same raw screens, and the structured-parser layer that turns them into product is ours, not ScreenLake's. The deal reduces to the patents — and whether term-matching claims even reach a parser-based system is now an open question. If the IP opinion says yes, and the claims are broad and likely to grant, a disciplined defensive bid is justified. If not, the right answer is to pass — or pick the patents up only if they go cheap. Get the opinion, skip Digitox, and let that one narrow question decide.