ASO Patents

Patent number	US20250265066A1 (pending application)
Official title	Techniques for managing images associated with software applications
Assignee	Apple Inc.
Inventors	Jia Huang, Anikesh Kamath, Babak Seyed Aghazadeh, Dayvid Victor Rodrigues de Oliveira, Justin M. Platz, Kanishka Bhaduri, Milind Pandurang Jagre, Robert J. Monarch, Yuan Yen Tai, Xiaoyuan Gu, Alex J. Kim
Priority date	February 21, 2024, via provisional application 63/556,382
Filed	February 21, 2025, application 19/060,399
Published	August 21, 2025
Claims	20 claims. Three independent, numbered 1, 9 and 17, carrying the same method as a method, a storage medium and a device
Status	Pending. Not granted, so it confers nothing yet
Source	patents.google.com/patent/US20250265066A1

What This Patent Covers and Why It Matters for ASO

Feature it describes: a tool inside the app submission flow that takes a screenshot or marketing image a developer already has, keeps the parts that matter, and redraws everything else to suit a given keyword.

It is worth being precise about what this is and is not, because the title sounds broader than the document. Nothing here replaces your screenshots behind your back. The store is not quietly rewriting your product page. What the patent describes is closer to a feature in App Store Connect: you upload an image, the system hands back enhanced variants of it, you look at them next to your original, and you choose.

The reason it matters for ASO is the unit of work. The whole design assumes that one creative per keyword is the right granularity, and that making them by hand does not scale. Apple says so directly in the background section:

“For example, to reflect the keywords ‘fast food’ and ‘vegetarian,’ distinct images need to be gathered/produced, merged together in an aesthetically pleasing way, and so on, which can be a challenging endeavor for those who lack design expertise or confidence.”

“In view of the large volume of search terms frequently provided by users, trying to create digital assets, customize them, and evaluate them, presently requires substantial human involvement.”

That is the thesis in two sentences. The keyword set is the size of a store’s search log. You cannot staff a design team against it. So the creative gets generated per keyword instead, from one image you already made.

There is a second, smaller finding buried in the same document, and it is the one with the longer reach. The inputs to this pipeline, the image and the keywords, do not have to come from the developer at all:

“when a submission is made, the distribution entity 102 can provide original images 104 and keywords 105 associated with the software application 103. Alternatively, or additionally, original images 104 and keywords 105 can be automatically generated for the software application 103.”

“one or more entities (e.g., the distribution entity 102, the server computing device 108, and/or other entities) can execute the software application 103, analyze its components, assets, logic, etc., to extract relevant screenshots from the software application 103 (e.g., screenshots of a primary UI, screenshots of relevant features, etc.), to identify relevant keywords, and so on, for the software application 103.”

Run the app. Read its components, assets and logic. Take your own screenshots of its primary interface. Work out the keywords from what is in there. That is one sentence in a long document, it is not in any claim, and the method behind it is never described. But it is Apple writing down that the store can derive an app’s screenshots and its keywords without the developer’s help.

Three things follow for practitioners.

• Your uploaded image is treated as a layout, not a picture. The system pulls your headline text and your device mockup out as protected foreground and treats everything behind them as replaceable. An image with a real interface and a clear headline gives it structure to work with. A flat gradient with a slogan gives it almost nothing to preserve.
• Keyword level creative stops being a budget question. If variants are generated rather than designed, the reason most teams run one creative set across many keywords disappears. Plan for the case where the tail gets its own art.
• What is inside your app is describable surface. In the automatic path, your in app copy, screen titles, feature names and asset names are what the store reads. They were never an ASO lever. In this design they are an input.

The usual caveat, and it carries weight here. This is a published application, not a granted patent. It confers nothing, the claims have not survived examination, and an application describes what a team designed rather than what the store runs.

Patent Summary

Claim 1 covers a method with six steps. A computing device receives an original image associated with a software application, where that image contains at least one foreground element. It extracts the foreground element, which produces two things: the element itself, and a modified original with the element removed. It generates two or more candidate images from three inputs, the extracted foreground, the modified original, and at least one keyword associated with the original image. It generates a quality score for each candidate, based at least in part on that same keyword. It filters the candidates by score. It associates one of the survivors with the software application.

Claims 9 and 17 are the same method as a storage medium and as a device. There are 20 claims in total.

The original image and the keywords can come from the developer at submission, or the system can derive both by running the application and analysing its contents.

Detailed Explanation

What counts as foreground

Start with the worked example, because it settles what this actually does to a screenshot. In FIG. 2A the input is a food delivery marketing image. The foreground the system identifies is:

“foreground elements included in foreground elements/masking information 111 include the text ‘Affordable Meals At Your Fingertips!’ included in the original image 104, as well as the smartphone device/screenshot included in the original image 104.”

Your headline and your phone mockup are kept. Everything else is cut away and repainted. The detection step is explicitly trained for this shape of asset:

“The UI detection operations can also involve detecting screenshots of software applications, computing devices that execute the software applications, and so on, which are commonly included in marketing materials for software applications.”

So the thing being redrawn is the background and the scene, not your interface and not your copy. An App Store screenshot in the usual format, a device frame with a caption above it, is exactly the input this was built for.

Stage one: cutting the layout apart

The masking engine runs “foreground element detection, segmentation, and mask post-processing operations”.

“the foreground element detection operations can involve utilizing a pre-trained detection model (e.g., a CenterNet model) to identify foreground elements included in the original image 104 (e.g., buttons, checkboxes, radio buttons, text fields, dropdown menus, …)”

“the segmentation operations involve providing the aforementioned bounding boxes to a pre-trained segmentation model (e.g., a Segment Anything Model) to obtain refined segmentation masks”

A pixel entropy filter then decides which masks survive. Masks “that correspond to high-entropy regions of the original image can be retained (e.g., those that satisfy a predefined threshold), while others can be disregarded”. Entropy stands in for visual busyness, so flat regions get dropped and detailed ones get kept. The edges then get “dilation and Gaussian blurring” so the new background blends instead of cutting.

Your text is read as well as kept. “optical character recognition (OCR) can be utilized to extract text content from the text elements”, and that text is not thrown away: “the text content can be used to supplement, refine, etc., the keywords 105 that are provided along with the original image 104.” The words in your screenshot feed back into the keyword set that drives the generation.

Stage two: repainting the rest

“the image generator 112 can implement three different weights of the stable diffusion model, including a pre-trained Stable Diffusion inpainting model, a pre-trained Stable Diffusion XL (SDXL) model, and a fine-tuned Stable Diffusion model.”

The masking information travels with the image so the generator knows “where inpainting should be performed”. The keyword builds the prompt, which is then padded with generic quality terms, quoted as “best quality,” “clear image,” “abstract,” “realistic style”.

The negative prompt list is the more revealing one:

“negative prompts can be incorporated to function as safeguards to help avoid undesirable components from being incorporated into the candidate images 113, e.g., ‘not safe for work (NSFW),’ ‘text,’ ‘logo,’ ‘low quality,’ ‘weird,’ ‘blurry,’ and so on.”

Text and logo are suppressed in the generated regions. The model is not inventing new copy or new branding. Your words stay yours because they were lifted out as foreground before any of this ran.

Stage three: the selector, and what it actually is

This is the part that ties the filing to the rest of Apple’s creative work, because the model is named outright:

“the image selector 114 can implement a pre-trained cross-modal image-text matching architecture, e.g., Learning Cross-Modality Encoder Representations from Transformers (LXMERTs), where the input text is processed by a WordPiece tokenizer and translated to word embeddings, and where candidate images 113 is processed by a Faster R-CNN object detection model”

LXMERT is the same architecture Apple used in its cross modal creative selection work, the one trained on advertising creatives that earned clicks and conversions. Here it is fine tuned into a classifier:

“the image selector 114 can be fine-tuned as a sequential model built on top of a LXMERT Encoder, and can include a linear layer, a Gaussian Error Linear Unit (GELUE) activation function, a normalization layer, another linear layer, and a sigmoid activation function as the last layer to output a binary classification prediction.”

A sigmoid producing a binary prediction means the question being asked of each candidate is not how good is this, it is does this match the keyword or not. The quality score is a match probability.

Two other jobs sit on the selector. It removes failures: it “can also be configured to identify and eliminate any candidate images 113 that are considered to be ‘AI hallucinations’”. And it can explain itself, through “an explanation agent that can be configured to provide explanations for candidate images 113 that were filtered out by the image selector 114.”

The submission flow, step by step

FIGS. 3A and 3B walk through the product, and this is the part that settles the question of who decides.

• Interface 310 takes a short description of the app, the one “that will be displayed on a product page”, and one or more keywords.
• Interface 320 prompts the developer “to upload at least one marketing image that was generated for the software application”, then indicates that the image “is being processed”.
• Interface 330 reports that variations were generated, shown as “Enhanced Image 1” and “Enhanced Image 2”, and lets the developer view both “as well as the original image 104 for comparison purposes”.
• Interface 340 shows a full preview of the chosen variant.
• Interface 350 appears after “Go Back” is selected, and “provides an option to select different images to be associated with the software application”.
• Submit, and interface 360 shows the product page carrying the selected image.

Upload, compare against your original, pick, submit. The developer is in the loop at every step. Apple’s stated benefit is not that this happens without you, it is that it happens cheaply: the result is “an enhancement to the original image 104 with exceptionally little input, work, etc., required from the distribution entity 102.”

What the system is allowed to consult

One detail that is easy to skim past. All three components, the masking engine, the generator and the selector, “can be configured to interface with knowledge sources 118”. Those sources are spelled out, and they are not local. They include web search engines that “crawl the Internet”, question and answer knowledge bases, and knowledge graphs, described as “a structured representation of knowledge that captures relationships and connections between entities, concepts, data points”.

So the context available when your creative is generated is not limited to what you uploaded. The design permits the open web and a knowledge graph to inform what gets drawn.

Bounded generation

“the embodiments can employ a diffusion model that is tuned using a set of (image, text) pairs that have been deemed to be relevant/appropriate to the types of images described herein. Such tuning can effectively establish a bounded generation process, which can help avoid the generation of inappropriate or policy-violating images.”

The background puts the worry plainly: general purpose models “frequently generate distorted, unrealistic, or even inappropriate images, which can lead to a poor user experience”. The constraint is applied three times over, by narrowing the training data, by the negative prompts, and by the hallucination filter in the selector.

What this patent does not tell you

• It never says how keywords would be generated automatically. It says they can be, and that the system runs the app and analyses its components, assets and logic. The method itself is absent, and none of it is claimed.
• It does not say generated keywords are shown to anyone or used in ranking. It establishes only that they can be derived.
• It is not about tags. The word never appears in the metadata sense. The keywords here are creative targeting terms like “fast food” and “vegetarian”, the kind you would bid on, not a browse taxonomy.
• It gives no evaluation numbers. No accuracy, no lift, no test of whether enhanced images outperform originals.
• It does not say this ships. Interfaces 310 through 360 are explicitly “merely exemplary and should not be construed as limiting”.

The narrow reading, then. In February 2024 Apple filed a description of a submission tool that takes one marketing image, protects the headline and the device inside it, repaints everything else from a keyword, scores the results with the same cross modal model it uses to pick ad creatives, and shows the developer the variants to choose from. Alongside it sits a single sentence saying the store could derive the image and the keywords itself by running the app. The first part is built out in detail and claimed. The second is one line and claimed nowhere, which is exactly why it is worth keeping an eye on.