| Patent number | US10394838B2 |
| Official title | App store searching |
| Assignee | Apple Inc. |
| Inventor | Edwin R. Cooper |
| Priority and filing date | November 11, 2015 |
| Granted | August 27, 2019 |
| Status | Active. Maintenance fee paid February 15, 2023. Anticipated expiry November 18, 2037 |
| Family | US20170132294A1 (published application) |
| Source | patents.google.com/patent/US10394838B2 |
What This Patent Covers and Why It Matters for ASO
Feature it describes: how an App Store result page is assembled, and specifically how the store decides which apps count as similar to a given app.
This is one of the most consequential patents on this site and one of the few still in force. Apple paid the maintenance fee in February 2023, and the anticipated expiry runs to 2037.
It describes a three tier result layout for a search that names an app:
- The searched application, as the top hit
- Applications determined to be similar to it
- Text matched results drawn from application metadata, last
Read the third tier carefully, because it inverts how most ASO work is prioritized. On a query that names an app, metadata text matching is the bottom tier. Everything above it is allocated by what users downloaded.
The second tier is where the opportunity sits. Similarity between two apps is not derived from category, from keywords, or from anything a developer writes. It is derived from overlap in the functional queries that led to downloads of each app. If people who search a task phrase install your app, and people who search that same phrase also install a competitor, the system associates the two of you.
Ranking inside that tier uses a score the patent calls an AppScore, which accounts for how frequently each query occurs and for the strength of association between an app and a query. Strength of association has a precise definition in the claim: the proportion of an app’s downloads that came from that query.
What this means in practice:
- Appearing next to a competitor on their own brand search is achievable organically, and metadata is not the lever. Shared functional query conversion is.
- Because strength of association is a proportion rather than a count, a smaller app that gets most of its installs from one functional query can outscore a large app that gets a small share of its installs from the same query. Concentration beats volume here.
- Spreading your acquisition across many unrelated queries dilutes every association you have. Focus is rewarded by the mathematics of the claim, not just by good practice.
- The query classification step this patent relies on comes from US9405832B2. Only functional queries feed the similarity graph, so brand terms contribute nothing to it.
The usual caveat applies. A granted and maintained patent shows what Apple designed, claimed and continues to pay for. It does not prove the method is running in today’s App Store in this exact form.
Patent Summary
The system collects distribution data for search queries, where distribution data records how many downloads of which applications followed the results produced by a given query. Using that data it classifies each query as either functional or navigational, the same distinction set out in Apple’s 2012 query classifier family.
For a given application, it then determines the set of functional queries that led to downloads of that application. It compares that set against the functional query sets of other applications. Where the sets overlap, the system creates an association between the applications, and that association is weighted by the frequency of the queries involved and by the strength of association between each application and each query, defined as the proportion of the application’s downloads attributable to that query.
At search time, the stored associations are used to build the result set: the app itself first, its associated similar apps next, and conventional text matches afterwards.
The economic logic behind the design is worth stating plainly. A user searching for a specific app by name has already decided what they want. Returning only that app wastes the rest of the screen. Returning apps that satisfy the same underlying need turns a navigational query into a discovery surface, and it does so using data no competitor can see.
Detailed Explanation
The patent’s official title is App store searching, and that is the honest scope. Similar apps are the output, but the machinery described underneath is the App Store’s query understanding layer: what gets logged, how every query in the store is sorted into two kinds, and how a single number ties a query to an app. This section walks the whole mechanism in the order the patent builds it.
Step one: what the App Store writes down
Everything here runs on one data structure the patent calls distribution data, and the patent is unusually specific about how it is collected. It states that “the app store stores one or more logs of queries used by users and downloads that resulted from those queries.”
The attribution is session based, not guessed. In the patent’s words, “the app store keeps track of the particular search session that a user engages in with the app store and follows the path of the user’s interaction within the search session in the app store in order to determine that the user has made a selection from a search result which was provided in response to a particular search query.” And the record itself: “requests to download are stored in logs along with at least the search query which immediately preceded the download request so that the system’s logs store an association between a download request for an app and a preceding search query that resulted in that download.”
Read that last line carefully. The unit of record is the query that immediately preceded the download. Not the query that started the session, not a weighted set of everything the user typed. The last query before the tap takes the whole credit. Every number in the rest of this patent is built on that single attribution rule.
Step two: sorting every query into one of two kinds
Before anything is scored, each query is classified. A functional query is one where “it is estimated that users are searching for an app that performs a function or provides a capability.” A navigational query is one where the user already knows the app they want.
The test is not linguistic. Nothing in it looks at the words. It looks at the shape of the download distribution the query produces. A query is classified as navigational “when the distribution data indicates a small number (e.g. less than 5 or less than 3) of unique applications were downloaded” as a result of it. The patent gives a second, stricter form of the same test: navigational “when the distribution data indicates that a small number of unique applications were downloaded as a result of the search query, and for each of those small number of applications, their proportion is greater than a threshold, such as a predetermined threshold (e.g. more than 0.25).”
Claim 8 pins the number down. It requires that “the small number is less than 5.”
So the operative definition is: fewer than five distinct apps absorb the downloads, and each of the survivors takes more than a quarter of them. A query that splits its downloads across a dozen apps is functional by construction, whatever it looks like as text. A made up brand name nobody searches is not navigational in this system, because it has no distribution at all. Classification is earned by user behaviour, not asserted by the developer.
Step three: the functional query vector
For each app, the system assembles what the patent calls a functional query vector. It “specifies the most commonly used queries that are used (based on the distribution data) to search and download app A, and those queries have the strongest association (based on proportions of downloads) to app A relative to other apps.”
Two conditions sit in that sentence and they pull in different directions. A query has to be common, and it has to be disproportionately yours. A high volume query where you take a sliver of the downloads does not qualify on the second condition. A query that is uniquely yours but that almost nobody types does not qualify on the first.
This vector is the app’s identity inside the system. It is not the metadata, not the category, not the keyword field. It is the list of task phrases that both matter in volume and belong to you in share.
Step four: QueryScore, the one published formula
The strength of the tie between a query and an app is a single number:
QueryScore(Q, App A) = log(volume of Q) × (number of downloads of App A for Query Q)
The patent’s own gloss: “This query score represents the strength of association between a particular query and the app. Higher volume queries which are used more frequently than other search queries will tend to score higher.”
The interesting part is the asymmetry between the two terms. Query volume enters through a logarithm, so it is heavily compressed. Your downloads on that query enter linearly, at full weight. Ten times the search volume is worth roughly one additional unit of the log term. Ten times the downloads is worth ten times the score.
- Volume is a tiebreaker, not the prize. The formula says a head term is worth having, but only slightly more per download than a mid tail one.
- Winning the query is the prize. The term that scales without compression is your download count on that specific query.
- The practical consequence: a keyword you convert on is worth more than a bigger keyword you merely appear on. That is the opposite of how keyword lists are usually prioritised by search volume alone.
One thing the document does not do is justify the logarithm. There is no passage explaining why volume is compressed and downloads are not. The formula is stated and used. Anyone citing it should cite it as Apple’s stated design and not as a derived result.
Step five: from queries to candidate apps, and AppScore
With app A’s functional query vector in hand, the system walks each query in it and pulls, for that query, “a sorted list of candidate apps (based on numbers of downloads) created from the distribution data.” Every app that converts on the same task phrase becomes a candidate neighbour.
Candidates are then scored. The patent prints the second formula as:
AppScore(CA1, Qn) = QueryScore(CA1, Qa) × (number of downloads(CA1, Qa))
The published text of this second equation is imprecise, with mismatched subscripts and an unclosed bracket, so it should be quoted with that caveat rather than presented as clean algebra. The intent is legible even so: a candidate app’s standing as a neighbour is its query score compounded by how many downloads it actually took on the shared query. Download share enters the similarity calculation twice, once inside QueryScore and once again outside it.
This is why the concentration argument in the section above is not a stylistic reading. It is what happens when a term is squared in effect while the volume term stays inside a log.
Step six: the filters that decide who is left
Four separate cut offs are described, and each one removes a different kind of weak signal.
- A volume floor on downloads. “a threshold can be set in order to eliminate low volume downloads which can remove ‘noise’ from the data.” A handful of installs on a query does not register at all.
- A volume floor on queries. A subset of queries is used “based upon a threshold value that requires the queries be used more frequently than a certain percentage of the usage of all queries.”
- Redundancy removal. “redundant functional search queries which tend to be low volume functional search queries can also be removed from the set of search queries that resulted in the download of app A.” Near duplicate phrasings of the same task collapse rather than each contributing separately.
- A minimum overlap between two apps. “the list of candidate apps for app A can be filtered by requiring that each candidate app meets the minimum number of queries in the functional query vector for app A,” and claim 8 fixes that minimum: “the overlap is required to be a minimum of 2 or more functional search queries.”
Two shared queries is the entry price for being considered similar to another app at all. One shared term, however well you convert on it, is not enough.
Step seven: assembling the page
The associations are precomputed and stored. FIG. 4 covers the method to “determine a set of functional queries for a given app in an app store.” FIG. 5 covers the method to “determine a set of other apps that appear to be similar to a given app based upon distribution data.” FIG. 7 shows “an example of a data structure that stores the association between an app and other similar apps.” Nothing in the patent says how often that structure is rebuilt.
At query time, for a navigational query, claim 4 sets the layout:
“The search results also include a second set of other applications that are found based on textual matches with application metadata in application description pages provided through the app store, and wherein the search results are sorted to show the results in an order in which the first application is listed first and then the first set of other applications and then the second set of other applications.”
Named app, then behaviourally associated apps, then metadata text matches. The tier every ASO workflow optimises for is the one the claim puts last.
What is claimed versus what is only described
The patent has 16 claims and two independent ones, claim 1 as a method and claim 9 as the same method on a machine readable medium. That is worth separating from the specification, because the two carry different weight.
- In the claims: collecting distribution data; classifying queries as functional or navigational from that data; deriving an app’s functional query set; associating apps by overlap in those sets; weighting the association by query frequency and by strength of association, which claim 1 defines as “a proportion of downloads of the application based on the query”; the fewer than five threshold; the minimum overlap of two queries; and the three tier result order.
- Only in the specification: the QueryScore and AppScore formulas, the 0.25 proportion threshold, the noise floors, and the redundancy removal.
That split matters for how you cite this. The published formula is real and it is Apple’s, but it survived into the description rather than the claim, which means the examiner did not treat it as the novel part. The defended invention is the idea of building app similarity from query level download proportions. The arithmetic is one way of doing it.
What this patent does not tell you
Being clear about the gaps is as useful as the findings.
- It does not describe how results are ranked within the third tier, the metadata matched one. That ordering is left open.
- It does not describe the ranking of a functional query’s own result page. The scoring here produces app to app associations, not the ordering a user sees when they search a task phrase.
- It gives no update cadence for the association data.
- It predates the modern ranker entirely. Apple’s own 2026 paper describes the live App Store ranker as a multi objective learning to rank model trained on clicks and downloads alongside human relevance labels, and that model appears in no patent at all.
So the correct reading is narrow and still valuable. This is the documented, still maintained description of how the App Store turns its own download logs into a map of which apps substitute for which. Priority runs from November 2015, the grant is in force to 2037, and Apple paid the maintenance fee in February 2023. What it is not is a description of the ranking function.
Related reading: US9405832B2 on query classification, and US9280595B2 on concept matching.
Bir yanıt yazın