Application Number: AU 2026202153

The App That Picks the Right Browser Profile Screenshots, OCR and On Device Machine Learning

Claim 1 is a computer implemented method with a strict order of operations. A control application is implemented by at least one processor and memory on a user device. That control application receives user profile data relating to the profiles of an application on the device. It then receives a URL for a resource from

Open for Public Inspection
AU 2026202153 Featured Image

View the The App That Picks the Right Browser Profile PDF

Download the PDF version of this Application Open to Public Inspection

Anyone who keeps separate work and personal browser profiles knows the specific irritation this application is about: you click a link in a chat app and it opens in whichever profile happened to be used last, which is usually the wrong one. This application claims a method for solving that automatically. A small control application sitting on the device intercepts the link, takes a screenshot of the app the link came from, reads features out of that screenshot, and uses a machine learning model built on the device to decide which browser profile the link belongs in. The applicant is 11point2 Pty Ltd, an Adelaide based venture and technology firm, and the application is a divisional of an earlier Australian filing.

The Problem

The specification starts from a premise that is now close to universal. The internet is used by a person on one device for both business and personal purposes, and often that person wants to keep the two separate. It then adds the case that makes the problem worse rather than better: a user may work across multiple organisations and want to segregate their use according to the organisation, so the split is not simply work against home but work A against work B against home.

Browsers already offer the mechanism. A user can set up multiple profiles, each with its own cookies, sessions, extensions and sign ins. The specification’s complaint is about what happens at the boundary. Whenever the user clicks a link to a URL from outside the browser, from a desktop application such as a chat client or a mail client, the URL opens in the last used browser profile. That may not be the desired profile, and the user is then required to take manual, time consuming action to get it into the right one.

The specification spells that action out, and the tedium of it is the point: open the desired profile tab, copy the URL out of the address bar of the wrong profile, paste it into the address bar of the right one. Individually trivial, and the specification’s argument is a cumulative one. Done a few dozen times a day across a working year, it adds up to a significant amount of wasted user time.

There is a second problem underneath the first that is not about convenience. Each profile may carry different authorisations and settings, so some URLs simply will not open on some profiles. Some of those settings are managed by a third party on remote servers. And, the specification notes, some information is neither able nor desired to be processed remotely from the user device, which sets up the constraint that shapes the entire claimed architecture: whatever solves this has to run locally.

What This Invention Does

Claim 1 is a computer implemented method with a strict order of operations. A control application is implemented by at least one processor and memory on a user device. That control application receives user profile data relating to the profiles of an application on the device. It then receives a URL for a resource from a further application on the device, in response to user input to that further application’s interface, which in plain terms means the user clicked a link somewhere that is not the browser.

At that moment the control application captures a screenshot image of at least the user interface of the further application. It extracts features from the screenshot associated with the URL. It builds a machine learning based model to predict profiles corresponding to the URL, using those features as training data along with the user profile data. It selects one of the profiles for opening the URL based on the model, outputs the selected profile to the application, and the application opens the URL using it.

The screenshot is the inventive move and the specification explains why it is there. A URL, it says, has only limited information and no other signals associated with it. The screenshot supplies the missing context. From it the model can work out where the URL came from, who shared it with the user, and which application it was received from. A link to the same document pasted by a colleague in a work chat and by a friend in a personal one is textually identical; the surrounding pixels are not.

Feature extraction runs on two tracks. Text features are pulled out using an optical character recognition engine, and the description states that the embodiment performs OCR with convolutional neural networks. Visual element features are handled by a separate feature extraction model, with the description noting that a user interface hierarchy is constructed from the detected elements so their location, type and semantic grouping can be used as signals. Both streams feed a classifier: the described embodiment uses a support vector machine to sort features into the categories attached to each profile, such as work and home, and the specification is careful to add that other classification models could be used instead.

The specification also gives a small worked example of the feature vector, and it is more illuminating than the claim language. One row pairs a URL with Outlook and no further detail, labelled work. Another pairs a different URL with Slack, capturing sender and receiver, labelled home. That is the entire model in miniature: URL plus source application plus the people involved, mapped to a profile.

Training is incremental and human supervised. The models are initially trained offline on annotated screenshots corresponding to URLs that are general to all users. The individual user then trains the classifier by choosing profiles for URLs in the control application’s interface, and later by accepting or correcting the profile the control application suggests. Dependent claims add user defined rules on top, so a particular site can be forced to a particular profile regardless of what the model thinks, and the description gives the example of always opening a given social media site in one profile whoever sent the link.

Two design decisions in the description explain why this is a separate application rather than a browser extension. The first is architectural: browser profiles compartmentalise the operation of the browser by design, so the browser cannot switch between its own profiles from within itself, which means the selector has to sit outside it. The second is that a separate control application can manage preferences across different browsers, which an extension cannot.

Key Features

  • A screenshot as the missing signal. The control application captures the interface of whatever application the link was clicked in, on the grounds that a bare URL carries almost no context while the surrounding screen carries the sender, the receiver and the application identity.
  • Two feature streams into one classifier. Text is read from the screenshot with an OCR engine and visual elements are handled by a separate extraction model, with both sets of features classified into the categories attached to each browser profile.
  • Everything stays on the device. The specification puts privacy first among its stated advantages, noting that keeping the control application local means the user’s personal and private information is never transmitted off the device, and that speed and performance improve as a result.
  • Screenshots are deleted on a timer. Dependent claims cover saving the screenshot to memory for a designated time and then deleting it, and the description gives the reason as disk management, since a heavy link user would otherwise accumulate a large image store.
  • Trained by correction, not configuration. After an offline initial training pass on generic annotated screenshots, the model is refined by the user selecting profiles and then by accepting or overriding the profile the control application suggests.
  • User rules override the model. Profile data can include rules the user writes, so a nominated site always opens in a nominated profile irrespective of which application the link arrived in or who sent it.

Who Is Behind It

11point2 is an Adelaide based firm that describes itself as sending experienced entrepreneurs into large organisations to find and build high value opportunities, working across deep tech, clean energy, artificial intelligence and national capability. It is registered in Australia and based at Lot Fourteen, the innovation precinct on the site of the former Royal Adelaide Hospital, where it appears in the precinct directory. The firm’s own positioning is that it does not consult but builds, which is a reasonable description of an advisory business that also files patents on working software.

Five inventors are named, and three of them appear on the company’s leadership page. George Freney is a founding partner whose earlier ventures span travel technology and retail. Rajat Kulshrestha is a founding partner based in Sydney and, by the company’s account, was chief technology officer of Microsoft Australia and New Zealand at the age of twenty three. Mark Ogden is managing director in Adelaide, with a background as a consultant, chief executive and board member. The remaining two named inventors, Nikhil Singh and Ashleigh Greaves, are not identified on that page, and the specification says nothing about any of them.

It is worth being clear about what this filing does and does not tell us. The specification describes an embodiment, not a shipped product, and it names third party applications such as Slack, Microsoft Teams and Zoom only as examples of where a link might come from. Nothing in the document identifies a commercial product, and the article makes no claim that one exists.

The priority position is short and should be reported exactly as the specification states it. The technical field paragraph says that AU 2026202153 is a divisional of Australian patent application 2024216941, whose contents are incorporated by reference. That is the only priority statement in the document. There is no reference to a provisional, a PCT application or any foreign application anywhere in the text, so the priority country recorded here is Australia and nothing further should be read into it.

Why It Matters

The underlying problem is a consequence of how the last decade of work software has been built. Identity moved into the browser, and browser profiles became the container for signed in sessions almost by accident rather than by design. The operating system, meanwhile, still thinks in terms of one default browser and one default handler for a link, a model that predates all of it.

That mismatch is where the friction lives, and it is not only irritating. A link opened in the wrong profile fails in confusing ways: an authorisation error rather than a clear message, or worse, a silent success under the wrong identity. For anyone working across several client organisations, which is precisely the applicant’s own line of work, the wrong session is a real risk rather than a nuisance.

The technical choice that gives this application its character is doing the inference locally. Reading a screenshot of a user’s chat window is a genuinely sensitive act, and a version of this that shipped those images to a server for classification would be difficult to defend in most workplaces. Building the model on the device, keeping the training data in local memory, and deleting the screenshots after a set period are the mitigations the specification puts forward, and they are the reason the claim insists on the control application being implemented on the user device rather than merely available to it. It is a good illustration of why edge computing arguments in consumer software are usually privacy arguments wearing a performance jacket.

The vulnerable point is the same one every learned routing system has, which is the cost of being wrong. The specification’s answer is to keep the human in the loop: suggest, let the user accept or correct, learn from the correction, and let explicit rules override the model entirely. That is the right shape for a feature that sits between a click and its destination, where the user notices every mistake and none of the successes.

Related Concepts

  • Google Chrome – the browser whose profile feature created the compartmentalisation this method navigates.
  • Deep linking – the general problem of routing a link from one application to the right destination in another.
  • Statistical classification – the machine learning task the control application performs when it maps a feature vector to a profile.
  • Screenshot – the unusual input this method treats as its primary source of context.
  • Privacy by design – the principle behind keeping the model, the training data and the images on the device.

AU 2026202153 was published in the Australian Official Journal of Patents on 9 April 2026 and is open for public inspection. Patent applications represent inventions that are sought to be protected and do not necessarily reflect commercially available products.

Related Patents Open to Public Inspections

See related Patents open to public inspection.

Disclaimer

The information presented in this article is provided for general informational and illustrative purposes only.

Content on this page may be derived from publicly available intellectual property records, including patent documentation and related materials. While reasonable care is taken in compiling and summarising this information, ATMOSS does not guarantee the accuracy, completeness, currency, or reliability of any content presented.

This article is not a substitute for reviewing the original source documents. Patent applications, specifications, claims, and related records may contain detailed technical, legal, and contextual information that is not fully represented in this summary.


ATMOSS does not provide legal, technical, or commercial advice. Users should not rely on this content for decision-making purposes.
For authoritative and up-to-date information, users should refer directly to the official records available via IP Australia and other relevant intellectual property databases. Links to these official sources are provided where applicable.


ATMOSS accepts no liability for any loss, damage, or consequences arising from the use of, or reliance on, the information contained in this article.