ASOpatents.com compiles a list of patents that are likely used to shape the algorithms of the Apple App Store, Google Play Store, and other major platforms. While it's uncertain whether these patents are actually implemented in the algorithms, the site provides insights into potential clues about search results, recommended apps, and other data points.

US8364694B2: How the App Store Decides What to Suggest While You Type

Patent US8364694B2 — “Search Assistant for Digital Media Assets” Filed: October 26, 2007 · Granted: January 29, 2013 · Status: Active (expires 2028) Assignee: Apple Inc. · Inventor: Christopher Volkert Continuations: US8639716B2 (2013), US8943089B2 (2015), US9305101B2 (2015)


What This Patent Covers

Every time you type a letter into the App Store search bar, a dropdown list of suggestions appears before you finish typing. These aren’t random. They’re not alphabetical. And they’re not based on what you’ve searched before. According to this patent, they’re ranked by purchase popularity — how frequently the corresponding apps or media are actually bought and downloaded.

This is Apple’s foundational patent for search autocomplete across all its digital stores — iTunes, App Store, Mac App Store, and any other media repository Apple operates. Filed in October 2007, just months after the original iPhone launch and before the App Store even existed, it has been continuously renewed through three continuation patents spanning nearly a decade of refinement.


How Autocomplete Works: The Five-Step Pipeline

When you type a character into the search bar, here’s what happens behind the scenes:

Step 1: Your keystrokes go to Apple’s server

This isn’t happening locally on your phone. Each character you type triggers a request sent over the network to Apple’s media repository server. The patent describes this as a “search hints request” that includes the character string you’ve typed so far.

This is why search suggestions sometimes lag on slow connections — they’re coming from Apple’s servers in real time, not from your device.

Step 2: The server finds all matching terms

The server stores a master list of all searchable terms associated with every digital media asset (app, song, movie, podcast) available in the store. These terms come from titles, artist names, developer names, and other metadata.

The server compares the prefix of each stored term against the characters you’ve typed. If you type “pho,” the server finds all terms starting with “pho” — “photo editor,” “photo collage,” “photoshop,” “phone cleaner,” “phoenix,” etc.

The patent describes the underlying data structure as a trie (also called a prefix tree) — a tree-shaped data structure specifically optimized for rapid prefix lookups. Each node in the trie represents a character, and following a path from root to leaf spells out a complete term. This makes the lookup extremely fast even across hundreds of thousands of terms.

Step 3: Results are filtered by what you can actually access

Not every app is available everywhere or on every device. The server removes suggestions for:

Geographic restrictions — If you’re in Germany, apps not available in the German App Store are removed from suggestions. You’ll never see autocomplete hints for apps you can’t actually download.

Device compatibility — If your device doesn’t support a particular media type or app, those suggestions are filtered out. An iPhone user won’t see suggestions for Mac-only apps.

This filtering happens server-side, meaning Apple uses your device type and location to personalize which suggestions you see — before any ranking happens.

Step 4: The remaining suggestions are ranked by sales popularity

This is the critical step for ASO. After filtering, the remaining suggestions are ordered based on how frequently the corresponding digital media assets are purchased or downloaded.

The patent is explicit about this: suggestions are “ordered in accordance with the frequency at which purchases of respective digital media assets occur.” A dedicated popularity module periodically accesses the store’s financial/transaction database to calculate and update popularity scores for every item.

In plain English: the more downloads an app gets, the higher its name appears in autocomplete suggestions. “Photo editor” might appear above “photo collage” simply because apps matching “photo editor” generate more total downloads.

The popularity data is updated periodically — the patent mentions hourly or daily refresh cycles. So a sudden spike in downloads (from a viral moment, a feature by Apple, or a large paid campaign) can push an app’s associated terms higher in autocomplete within hours.

Step 5: A subset of the top suggestions is sent to your device

The server doesn’t send every match. It selects a subset — the top-ranked suggestions after filtering and ordering — and sends them back to your device. These appear as the dropdown list below the search bar.

The whole process repeats with every keystroke. Type one more letter and a new, more refined request goes to the server, returning updated suggestions.


The Trie Data Structure: Why This Matters Technically

The patent describes using an augmented trie (prefix tree) as the core data structure for storing search hints. A standard trie efficiently stores words that share common prefixes. Apple’s version adds three additional pieces of data to each node:

Sales popularity score — So suggestions can be instantly ordered by download frequency without a separate lookup.

Geographic availability flags — So region-filtered results can be returned without querying a separate database.

Media type indicator — So device-incompatible results can be filtered instantly.

By embedding all three signals directly in the trie, the system can find, filter, and rank suggestions in a single traversal of the data structure — no joins, no secondary queries, no delay. This is how Apple achieves near-real-time suggestion responses as you type.


Where the Popularity Data Comes From

The patent describes a specific data pipeline:

Finance database — Stores all purchase and transaction data. Every time someone buys or downloads a digital media asset, a record goes here.

Popularity module — Periodically scans the finance database and calculates popularity scores. The patent says this runs on a configurable schedule (hourly, daily, etc.).

Search terms module — Extracts all potential search terms from the content database (titles, names, metadata of all available assets).

Hints formation module — Combines the popularity scores with the extracted search terms and writes the combined data into the hints data structure (the trie).

Hints data structure — The pre-computed, ready-to-query trie that the search hints module accesses in real time when your keystrokes arrive.

This means autocomplete rankings aren’t calculated on the fly — they’re pre-computed from periodic snapshots of purchase data. The suggestions you see reflect a recent (but not instant) picture of download activity.


Key Finding #1: Popularity Rankings Update Hourly — Paid Campaigns Can Move Autocomplete

The patent states that the popularity module runs on a configurable periodic schedule, with hourly and daily explicitly named as examples. This is not a vague “updates regularly” — the patent architecturally separates the popularity calculation into a dedicated module that re-scans the finance database on a set interval and rewrites the popularity scores into the hints data structure.

This has a major practical consequence: a burst of downloads can shift autocomplete rankings within hours, not weeks.

Consider the implications. If you run an Apple Search Ads campaign or a Meta Ads campaign that drives a spike of downloads for apps associated with the keyword “vector design,” the popularity score for that term increases at the next refresh cycle. If that refresh is hourly, the autocomplete ranking for “vector design” could move up within the same day.

This also explains a phenomenon ASO practitioners have observed but couldn’t fully explain: why autocomplete suggestions sometimes change rapidly after major events. A new app going viral, a holiday-driven spike in a category, or a large-scale paid acquisition campaign can all shift what users see in autocomplete — because the underlying data refreshes frequently.

The flywheel effect is equally important. Once a term rises in autocomplete, more users tap on it instead of typing their own query. More taps mean more searches for that exact term. More searches mean more downloads for the top-ranking apps. More downloads mean higher popularity scores. Higher popularity scores keep the term high in autocomplete. It’s a self-reinforcing cycle, and the hourly refresh rate means it can spin up fast.

The reverse is also true. If downloads for apps associated with a term decline, the popularity score drops at the next refresh, the term falls in autocomplete, fewer users see it, and fewer searches happen. A declining term can fall out of suggestions within days.

For ASO strategy, this means:

  • Time your download pushes. A coordinated campaign that concentrates downloads into a short window has more autocomplete impact than the same number of downloads spread over weeks — because each hourly/daily refresh captures a higher instantaneous velocity.
  • Monitor autocomplete changes as a leading indicator. If your target keyword is rising in autocomplete position, it means aggregate downloads for that term’s apps are increasing. If it’s falling, download velocity is dropping across the category.
  • Paid and organic work together through autocomplete. Apple Search Ads don’t just drive direct installs — they can indirectly boost organic visibility by increasing the download velocity that feeds autocomplete rankings.

Key Finding #2: Prefix Matching Means the First Word of Your App Title Is Everything

The patent describes the core data structure as a trie — a prefix tree that matches characters strictly from the beginning of stored terms. This isn’t a detail buried in a technical footnote; it’s the fundamental architecture that determines what can and cannot appear in autocomplete.

Here’s what prefix matching means in practice:

If a user types “photo”, the trie returns terms that start with “photo” — “photo editor,” “photo collage,” “photoshop,” “photo booth.” It does not return “best photo app” or “my photo editor” because those terms start with “best” and “my,” not “photo.”

This has a direct consequence for app titles: the first word of your app title determines which autocomplete queries your app can appear in.

Consider two hypothetical apps:

  • “Curve – Vector Design” → The term “Curve” enters the trie. It matches when users type “cur,” “curv,” “curve.” But it does NOT match when users type “vector” or “design” — because the trie looks for “vector” at the beginning of the term, and “Curve – Vector Design” starts with “Curve.”
  • “Vector Design – Curve” → The term “Vector Design” enters the trie. Now it matches “vec,” “vect,” “vector,” “vector d,” “vector design.” This app appears in autocomplete for the much higher-volume functional query.

The patent extracts terms from titles and metadata — so individual words from the title may also be indexed separately (meaning “Curve” and “Vector” and “Design” could each be separate terms in the trie). But the full compound term — the complete phrase as it appears in the title — is matched as a prefix. And in autocomplete, full phrase matches are what users see and tap.

This means:

  • Lead your app title with your highest-value keyword, not your brand name — unless your brand is the keyword people search for. “Linearity Curve” starts with “Linearity” which matches “lin,” “line,” “linearity” — useful for brand searches but invisible for “vector” or “design” autocomplete.
  • The subtitle and keyword field may generate separate trie entries, but the title is the primary source of compound terms. “Vector Graphic Design” as a title creates a compound trie entry that matches “vector,” “vector g,” “vector graphic,” “vector graphic design” — capturing the entire long-tail.
  • Avoid filler words at the start of your title. “The Best Photo Editor” wastes the most valuable position on “The” — a word that matches millions of terms and provides no differentiation. “Photo Editor – Best Filters” puts the high-value keyword first.
  • Study what actually appears in autocomplete for your target keywords. Those suggestions are the compound terms with the highest download-weighted popularity scores. If your app’s title phrase isn’t among them, you’re either not generating enough downloads or your title doesn’t match the prefix pattern.

Additional ASO Implications

Autocomplete suggestions are a direct reflection of download velocity. If your app’s name or primary keyword appears in autocomplete, it means enough people are downloading apps associated with that term to push it above the display threshold. Conversely, if your target keyword doesn’t appear in suggestions, it either has low search volume or the downloads associated with it are too low.

Getting into autocomplete is a compound advantage. Once a keyword appears in suggestions, more users select it (because it’s easier than typing), which generates more downloads for the top-ranking apps for that term, which reinforces the term’s popularity score, which keeps it in suggestions.

Your app title directly feeds the term pool. The search terms module extracts searchable terms from app titles and metadata. If your app title contains a clear, commonly-searched term, that term enters the autocomplete candidate pool. Obscure or branded-only titles may never enter the suggestion system at all.

Geographic filtering means different markets see different suggestions. The autocomplete list in Japan is different from the one in the US — not just because of language, but because the popularity rankings are filtered by geographic availability. An app that dominates downloads in one region may not even appear in suggestions in another.


The Patent Family: Nearly a Decade of Refinement

This patent was filed before the App Store even launched, and Apple has continuously refined it:

PatentFiledGrantedWhat It Adds
US8364694B2Oct 2007Jan 2013Original — sales popularity ordering, geo filtering, trie structure
US8639716B2Jan 2013Jan 2014First continuation — refinements to the same system
US8943089B2Dec 2013Jan 2015Second continuation — further refinements
US9305101B2Jan 2015Apr 2016Third continuation — extended claims

Four patents spanning 2007–2016, all from the same original inventor (Christopher Volkert), all refining the same core system. This level of sustained investment tells you this mechanism is fundamental to how Apple’s store search works.


Technical Details

FieldValue
Patent NumberUS8364694B2
ApplicationUS11/925,599
FiledOctober 26, 2007
GrantedJanuary 29, 2013
StatusActive (expires August 5, 2028)
InventorChristopher Volkert
AssigneeApple Inc.
ClassificationG06F 16/9538 (Presentation of query results); G06F 16/90324 (Query formulation using system suggestions)

Patent source: US8364694B2 via Google Patents

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir