Correction. An earlier version of this article presented US 2023/0095944 A1 as an Apple patent about App Store search suggestions. That was wrong. The publication is titled “Transaction tags for enhanced searching” and it concerns searching your own payment transaction history on device, in a wallet or payment card context. It has nothing to do with app store search. The article is kept, rewritten, because a wrong attribution left uncorrected is worse than a correction, and because the actual patent turns out to describe a suggestion mechanism worth understanding on its own terms. For App Store search suggestions, read US8364694B2 instead.
| Publication number | US 2023/0095944 A1 |
| Official title | Transaction tags for enhanced searching |
| Assignee | Apple Inc. |
| Inventors | Michael A. Minar, Yiran Kang, Fadi S. Obeid, Rachel Reddy, Rima Kakarla, Anuj Chaudhary, Anish Doshi, Julien Barlerin, Michael Artemiw, Richard W. Heard, Ashish C. Nagre, Thomas J. Miller |
| Priority date | September 24, 2021 |
| Filed | September 7, 2022 |
| Published | March 30, 2023 |
| Status | Granted, reported as US12505130B2 |
| Subject area | Payments and wallet, not the App Store |
| Source | patents.google.com/patent/US20230095944A1 |
What This Patent Covers and Why It Matters for ASO
Feature it describes: search over a user’s own transaction records, with suggested queries generated from automatically derived tags rather than from keyword matching.
Direct relevance to app store optimization: essentially none. There is no app catalog, no ranking of third party content, no metadata competition and no discovery surface that a developer can influence. Anyone citing this publication in an ASO context, including the earlier version of this page, has the wrong document.
It stays on the site for two reasons.
The first is method. This site is built on the premise that patents are readable evidence about how platforms work, and that premise only holds if the readings are checked. Publication numbers are easy to transpose, titles on aggregator pages are sometimes mismatched with abstracts, and a plausible sounding summary can survive for years unexamined. This page is now a worked example of the failure mode.
The second is that the suggestion mechanism itself is genuinely interesting, and two of its design choices are the kind of thing that does eventually migrate across Apple’s products.
- Suggestions come from derived tags, not from matching text against records. The system reads characteristics of each record, attaches tags such as recurring, expensive or a category, and then builds suggested queries from those tags. The suggestion vocabulary is generated by the system rather than typed by anyone.
- Suggestions can appear without a query at all. The system can surface a suggestion in response to a detected pattern, such as a recurring charge that has increased, rather than waiting for the user to start typing.
- Processing is on device. Records arrive from the service provider, are stored locally, and are tagged locally. Compare that with the app recommendation filings, which are server centric.
Whether any of that reaches App Store search is speculation and is labeled as such. A store recommendation surface that proactively suggests a query based on a detected pattern in your own behavior would be a meaningful change, and nothing here says Apple is building one for apps.
Patent Summary
A user device receives transaction data from a service provider, where each record carries a set of characteristics such as merchant name, amount, date and location. The device stores the records locally and determines tags to associate with individual records based on a subset of those characteristics, then modifies the records to include the tag data. When a request for transaction information arrives, the device identifies the matching set of records using those tags and presents the information.
“Enhanced searching at a user interface may be enabled by tagged transaction records. When a search query is received at the user interface, a user device may determine a set of suggested search queries. Selection of one of the suggested search queries causes the user device to provide a set of search results that are associated with each via at least one transaction tag defined by the selected suggested search query”
US 2023/0095944 A1, abstract
The interesting consequence of that architecture is that a search result set is defined by a tag, not by a text match. Selecting the suggestion is what defines the query, and the records returned are the ones carrying the tag that the suggestion names.
Detailed Explanation
What a tag is and where it comes from
A tag is a label the device attaches to a transaction record after inspecting its characteristics. The description draws on five input types.
- The transaction records themselves, with fields such as entity name, amount, date and location
- Location information from a location service, identifying geographic boundaries and the products or services associated with them
- Event data mined from the device’s calendar, email and ticketing applications
- The device’s own location, used to correlate the user’s presence with the timing of a transaction
- Account benefit information from the card issuer, such as cash back categories
The third and fourth are the ambitious ones. A charge on a date when your calendar shows a concert, at a location matching the venue, can be tagged as belonging to that event. The tag carries meaning the transaction record alone does not contain.
Users can also define their own tags. The claim language allows at least one of the tags to be user defined, which makes the tag vocabulary a mix of derived and manual entries.
The thresholds, which are the concrete part
Unusually for a patent in this collection, several specific statistical rules are described rather than gestured at.
| Tag or detection | Rule as described |
|---|---|
| Expensive | Transactions at or above roughly the 95th percentile, assessed against a normal distribution of the user’s transactions |
| Recurring, by amount | Minor differences in amount permitted within a tolerance specific to the transaction type |
| Recurring, by date | Occurrences within a threshold distance of a particular day of the month |
| Charge increase alert | Triggered when a recurring charge increase exceeds a threshold that varies by merchant, category and transaction stability |
| Top merchants | Identified by transaction count or total exceeding a minimum, with a figure such as 1,000 dollars in purchases given as an example |
Two observations. The expensive tag is relative to the individual, not absolute, so the same amount is expensive for one user and unremarkable for another. And the recurring detection tolerates drift in both amount and date, which is what makes it usable against real subscription billing rather than only against perfectly regular charges.
How suggestions are generated and ordered
When the user types, the device identifies tags that have been associated with a set of records and offers those as suggested queries. Suggestions also change depending on the set of transactions under consideration for a given time period, so the same typed characters produce different suggestions in different months.
Suggestions can also be surfaced without the user initiating a search, in response to a detected pattern such as a recurring price increase.
The document does not disclose a scoring algorithm for ordering suggestions, and no numerical scores are given. Suggestions appear to be organized by relevance to transaction characteristics, with prominence or recency as the apparent basis. That is a real gap in the disclosure and should not be filled by assumption.
What is claimed
Claim 1 covers receiving transaction data from a service provider at a user device, where the data includes records each associated with an individual transaction and a set of characteristics, storing those records on the device, determining one or more tags to associate with individual records based on a subset of their characteristics, modifying the records to include data representing the tags, and then, on receiving a request for transaction information, identifying a set of records based on those tags and presenting the associated information.
Note that the claim is about tagging and retrieval on the device. The search suggestions in the abstract are the application of the tags, and the on device storage is written into the claim itself rather than left as an implementation preference.
What this tells us about App Store search suggestions
Almost nothing, and that is the honest answer. The two systems differ in every structural respect. This one searches a small private corpus that belongs to the user, on the device, with no competition between publishers and nothing to rank against anyone else. App store search suggestion is a public corpus, served from Apple’s infrastructure, with commercial competition for a handful of slots.
The only defensible transfer is directional. Apple has a working design in which suggestions are generated from derived semantic tags and can be surfaced proactively from detected patterns. If that pattern ever reaches app discovery, the consequence for ASO would be significant, since it would mean the store proposing queries the user never formed. There is no evidence in this document that it has.
Read these instead
US8364694B2 is the actual Apple patent on store search suggestions, including the rule that the suggestion list is ordered by sales popularity. WO2023235143A1 covers the suggested results shown before the user types anything. US20240086412A1 covers personalized recommendations and the rewriting of search queries.
Bir yanıt yazın