ASO Patents

Patent number	US9280595B2
Official title	Application query conversion
Assignee	Apple Inc.
Inventors	Catherine A. Edwards, Natalia Hernandez-Gardiol
Priority and filing date	August 30, 2012
Granted	March 8, 2016
Status	Active. Anticipated expiry April 25, 2034
Family	US20140067846A1 (published application), US20160171091A1 (continuation), related to US8688728
Source	patents.google.com/patent/US9280595B2

What This Patent Covers and Why It Matters for ASO

Feature it describes: the relevance layer that decides whether your app is genuinely about a query, rather than merely containing the query’s words.

This is the patent that explains why keyword stuffing stopped working. The method it describes builds, for every search term, a vocabulary of other words that tend to appear in the apps people actually install after searching that term. Those companion words are called indicator terms. At search time the store does not only count how often your metadata contains the query. It checks whether your metadata contains the surrounding vocabulary that real matches carry.

The consequence is stated plainly in the description. An app with a high count of the literal search term but few related indicator terms can be ranked lower or removed from the result set entirely. An app with a modest count of the literal term but a rich supply of indicator terms can be promoted above it.

This is an active patent, granted in 2016 with an anticipated expiry in 2034, and it has a continuation still in the family. Of the query understanding patents on this site, it is the one most likely to describe live behavior.

What follows for keyword work:

• Repetition has a ceiling and a penalty. Once the literal term is present, additional instances add little, and an unusually high count with no supporting vocabulary is exactly the pattern this method is designed to catch.
• The words you would never bid on are doing work. For a mail app, “account”, “reply”, “message”, “filter” and “compose” may contribute more to relevance on the query “email” than a second instance of “email” does.
• The long description earns its place in ASO strategy here, not as a ranking field in the classic sense, but as the surface where indicator vocabulary lives. On iOS the description is not indexed for keyword ranking, so treat this as a statement of design intent about how Apple models relevance rather than as a claim about the iOS keyword field.
• Your competitors’ metadata is the cheapest available approximation of the indicator vocabulary for a term, because the second method in the patent derives it from co-occurrence across the whole catalog.
• Writing naturally about what the app does is not a soft recommendation under this design. Natural writing is how indicator terms get into your metadata in the first place.

The usual caveat applies. A granted patent shows what Apple designed and claimed. It does not prove the method is running in the App Store today, or in this exact form.

Patent Summary

The system starts from empirical queries, meaning the search terms people actually use. For each potential query term it identifies the subset of app documents that users were likely to click or download after entering that term. It then derives, from that subset, the terms that characterize a real match. Those derived terms become the term’s indicator vocabulary, stored in a term relationship structure that can be held as a vector or as a matrix.

When a query arrives, the store expands it from the literal words into that vocabulary, then scores candidate apps on how well they carry it. The patent offers a second, purely statistical route to the same vocabulary: analyze co-occurrence across every app document in the catalog and build an N by N matrix of which terms travel together. Both routes produce a relatedness score per term pair, and the scoring can be as simple as a document count or as involved as a download weighted, length normalized calculation with inverse document frequency applied.

“A set of potential search-query terms can be identified based on empirical queries for apps. For each potential search-query term, a subset of documents within a set of documents can be identified based on apps that users were likely to click on or download following entry of a search query with a comparable or same term.”

US9280595B2, abstract

Detailed Explanation

The example the patent opens with

A user searches “email”. Two apps are in contention.

App	Instances of “email”	Indicator terms present	Outcome under pure text matching	Outcome under this patent
Best Mail	Once in the title, once in the description	Many: account, reply, message, filter, compose	Ranked below Pool Game	Ranked first
Pool Game	Three times in the description	Almost none	Ranked first	Demoted or dropped

A pool game might mention email three times for ordinary reasons: invite a friend by email, email us your feedback, email the developer for support. None of those mentions make it a mail app. Counting occurrences cannot tell the difference. Asking whether the app also talks about accounts, replies, messages, filters and composing can.

That is the whole idea. The rest of the patent is two different ways of learning which words belong to which concept, and a scoring method for applying them.

What an indicator term is

An indicator term is a word that signals a document belongs to the concept behind a query, without necessarily being the query. It is not a synonym. “Electronic mail” is a synonym for “email”. “Compose” is not a synonym for anything in that query, but its presence is strong evidence that the app in question is a mail client.

Each query term ends up with a set of indicator terms and, in the richer version of the data structure, a relatedness score attached to each one. Figures 5A through 5C show the alternatives the patent contemplates: a plain vector of related terms, a vector with metrics attached, and a full matrix.

Method 1: learning from what users install

The first method, covered by Figure 7, is behavioral. The system looks at a query term, identifies the app documents that users selected or downloaded after searching it, and extracts the words that appear frequently across that winning set. The logic is that the crowd has already solved the relevance problem. Whatever vocabulary the apps people chose have in common is, by definition, the vocabulary of a real match.

This has a property worth dwelling on. The vocabulary is authored by the apps that already win the term. If the top installs for a query all describe themselves with a particular set of words, those words become the standard that new entrants are measured against. A newcomer using a different vocabulary for the same function is, in this model, measurably less relevant even when it is functionally identical.

Method 2: co-occurrence across the whole catalog

The second method, covered by Figure 4, needs no behavioral data at all. The system takes every app document it has and builds an N by N matrix where rows and columns are both potential query terms. For each term it counts how often every other term appears in documents that contain it. Terms that keep showing up together get high relatedness scores.

This is the method that matters most for practitioners, because it is reproducible without access to Apple’s data. Anyone can approximate it by collecting the metadata of the apps ranking for a term and counting which other words recur. Figure 8 describes a third variant based on keyword lookup, which sits between the two.

Which fields get examined

The description has the system analyzing app titles, descriptions and associated metadata, and it explicitly allows different fields to carry different weight, with title occurrences potentially counting for more than occurrences buried in a description.

Be careful how far you carry that into iOS practice. The patent is written in general terms about a store of software applications and its documents. It is not a description of the iOS metadata fields as they exist in App Store Connect today, and on iOS the long description is not part of the keyword index. The useful reading is narrower and still valuable: Apple’s model of relevance is built on the full text of what an app says about itself, and field weighting is part of the design.

How the scoring works

The relatedness metric between a query term and a candidate indicator term can be computed several ways, and the patent lists them as options rather than picking one.

• A simple count of documents in which both terms appear
• The same count weighted by download frequency, so popular apps contribute more to the vocabulary than unpopular ones
• Normalization by the number of documents, so common words do not dominate purely by being common
• Inverse document frequency, the standard information retrieval correction that rewards terms which are distinctive rather than ubiquitous

The download weighting option is the one with a direct ASO reading. If the vocabulary of a concept is weighted by install volume, then the market leaders in a category are disproportionately defining the language that everyone else is scored against.

How indicator terms change the ranking

Figures 6 and 9 cover search execution. Once the term relationship structure exists, a query is answered by scoring candidates on both the literal term and its indicator vocabulary. Two outcomes are described explicitly.

Apps with high literal counts and few indicator terms are ranked lower or eliminated. Apps with low literal counts and many indicator terms are given prominence. The second half of that is the part people underrate. This design does not only punish stuffing. It actively rewards apps that describe their function thoroughly even when they use the query term sparingly.

What is claimed

Claim 1 covers responding to a search query against a database of applications and their associated documents, by identifying a subset of documents based on empirical user actions, and proceeding from that subset. The full claim text runs considerably longer than the fragment reproduced on most patent aggregators, so read it at the source before relying on its precise scope.

The structural point is that the claim is anchored on empirical user actions. Method 2, the pure co-occurrence matrix, is described in the specification as an alternative, but the behavioral route is what the independent claim is built around. Apple’s protected position is the loop from installs back into vocabulary.

How to use this in practice

• For each target term, collect the metadata of the top ranking apps and count the words that recur across them. That recurring set is your working approximation of the indicator vocabulary.
• Audit your own metadata against that list. Missing indicator vocabulary is a relevance gap that no amount of repeating the head term will close.
• Weight your audit toward the apps with the most installs on the term, since download weighted co-occurrence is one of the scoring options in the patent.
• Stop treating high term density as a positive signal in metadata review. Under this design it is neutral at best.

Family and related patents

US20140067846A1 is the published application and US20160171091A1 is the continuation filed in January 2016, which means Apple kept pursuing protection on this line after the parent was granted. US8688728 is a related filing.

Both named inventors also connect outward. Catherine A. Edwards and Natalia Hernandez-Gardiol appear on US9405832B2, the query classifier, which decides what kind of search is happening. This patent then decides what the search means. The 2017 and 2025 filings on synonym clusters and vector embeddings replace this bag of words approach with geometry, and are the natural next step in the same story.