Invented by O’Brien; Jason Kenneth

Software updates are everywhere. They keep our apps safe, fix bugs, and add new features. But, they can be big and slow to download. This new patent application shows a clever way to make updates much smaller and faster. Let’s look closely at how this works, why it matters, and what makes it special.

Background and Market Context

Think about your phone. Every so often, you see messages to update your apps. Sometimes these updates are tiny. Other times, they seem to take forever, use a lot of your data, and fill up your storage. If you have a slow internet connection or limited storage, this can be a big problem.

For people with limited internet data, every megabyte counts. Even a small change to an app can lead to a big update file because of the way apps are built. When you want to update, your device usually downloads a “patch.” This patch holds the changes between the version you have and the new version. But traditional patches can be big, especially for apps with lots of connected parts inside.

Why are app updates so big? Here’s the main reason: apps are made up of many parts that talk to each other. These are called “references.” For example, one part of the code might call another part, or point to an image or sound file. If you change just a tiny thing, all these pointers can get mixed up. So, the patch has to include all these changes, not just the new code. This can make a tiny code fix into a big download.

This is a real pain for both users and app makers. Users may skip updates because they take too long or use too much data. Skipping updates means more bugs, more crashes, and more security problems. App makers want their updates to go out quickly and smoothly, but they don’t want to make users unhappy with big downloads.

With the rise of mobile phones and devices in every pocket, this problem is only getting bigger. It’s worse for people with slow or expensive internet connections. Even small updates can cost a lot in data. So, there’s a big need for smarter ways to make app updates smaller and faster.

This new patent application tackles this problem head-on. It promises a way to shrink update sizes by looking at how apps are built, not just at the raw data. The idea is to make updates that are much smaller, use less data, and work better for everyone. If successful, this could help millions of users save time, money, and storage space—all while keeping their apps safe and up to date.

Scientific Rationale and Prior Art

To understand this new approach, let’s first look at how updates have worked before, and why they fall short. In the old way, when an app changes, the update system tries to find the difference between the old app and the new app. It then sends only the difference, which is called a “patch.” This is usually done by comparing the two files, looking for matching chunks, and writing instructions like “delete this,” “insert that,” or “replace here.”

This sounds simple, but it does not work well for apps with lots of internal references. Here’s why: inside an app, many pieces point to each other. If you add, remove, or move even a small part, all the pointers can change. When that happens, the old patching tools see almost everything as different, even if the changes are small. So, the patch gets big, and you lose most of the savings.

Some patch tools try to be smarter. They look for patterns and try to ignore noisy changes. Some even try to spot pointers and treat them differently. But when there are too many references, or when the app’s structure changes a lot, these tools start to fail. They can’t match things up, and they end up sending big patches or even the whole new file.

Why does this happen? Because the old tools see the app as a string of bytes, not as a set of linked parts. When the structure changes, the byte order changes, and the patch tools lose track of what matches what. They get confused and just send the new data.

People have tried other tricks, too. Some split the app into chunks and patch each chunk. Others try to compress the patch, or to only update certain parts. But these methods all have limits when the app is full of pointers and links.

Let’s use an example. Say your app has a list of pictures, and each picture has a number. If you add a new picture at the start, all the numbers change. Now, every place in the code that points to a picture needs to change its number. The old patching tools see all these as changes and send them all over the network. Even though only one picture was added, the patch is huge.

This is the core problem: the more references an app has, the more likely a small change will cause lots of “noise” that makes patches big. This is especially true for apps built in languages or formats that use lots of pointers, such as compiled code for phones and games.

What’s missing is a way to look at the app’s structure, understand how things are linked, and make patches that focus only on what really changed. Instead of treating everything as raw data, we need to look at the app as a map of connected pieces.

The new patent application brings in this fresh idea. It uses graphs—a way to show things and their links—to see how the app is built. By mapping out the app and its connections, it can spot what really changed and make a much smaller patch. This goes beyond the old way of comparing bytes. It compares the app’s real structure and relationships.

This idea is inspired by work in computer science on graph theory, hashing, and matching. Graphs are a way to show things (nodes) and how they connect (edges). By using graphs, the method can match up the same parts in the old and new app, even if their positions have changed. It uses hashing—a way to turn data into a short code—to spot matching parts, even if their locations have moved. This smart matching lets the tool focus only on the true differences, not on the noise caused by pointers.

By using this approach, the patent promises much smaller patches, faster updates, and less wasted data. It takes what’s best from the old patching tools and adds a new layer of intelligence that understands how apps are really built.

Invention Description and Key Innovations

Now, let’s break down what this invention does and why it’s such a leap forward. The main idea is to use graphs to show how an app is built, then use smart matching to make updates much smaller.

Here’s how the process works, step by step:

When an update is needed, the system checks if the new version of the app is really different from the old one. If so, it starts by building a graph of each version. In this graph, each part of the app (like a piece of code, an image, or a sound) is a node. Each link—where one part points to another—is an edge. So, you get two graphs: one for the old app and one for the new.

Next, an algorithm looks for matching nodes in the two graphs. This is not just about matching by position or order, but by content and connections. The algorithm uses hashing, which turns each piece into a short code based on its data. If two parts have the same hash, they are likely the same. The algorithm keeps updating the hashes, taking into account both the data in each node and the hashes of the nodes they point to. This process goes on until all the easy matches are found.

Some nodes won’t match up right away, maybe because they are new, removed, or changed. For these, the system looks at their connections: if two unmatched nodes both point to the same matched nodes, they are probably the same, just in different places. By repeating this process, the algorithm pairs up as many matching nodes as possible, even when the app’s structure has moved around.

Once the matches are found, the system creates a “control file.” This file holds a set of “step functions”—instructions that describe how the references (the app’s pointers) have changed. These step functions are like a recipe: they tell the update tool how to turn the old app’s pointers into the new ones. Instead of listing every change, they use smart rules to describe patterns in how things moved. This is much more efficient and takes up less space.

With the control file ready, the system uses it to create a “mutated” version of the old app. This is a copy of the old app, but with its references updated to match the new app as closely as possible. At this point, the mutated app should be very close to the new version, except for the real changes that were made (like new code or images).

Now, the system runs a regular patch algorithm (like the old tools) to find the final differences between the mutated app and the new app. Because the mutated app already has the right structure and references, the remaining differences are small. The final patch file is now much smaller than if you had tried to patch the old app directly.

The last step is to send the control file and the patch to your device. When your phone gets the update, it uses the control file to update the references in its copy of the app, then applies the tiny patch. The result is a fast, small update that uses much less data and storage.

This invention also has some other smart touches. The control file can include extra information to help the patching process, like tips for deleting parts of the old app as soon as they are not needed. This helps save storage space during the update.

The patent also makes sure the system works for all kinds of devices, not just phones. It covers anything that runs apps: tablets, TVs, game consoles, and even cars.

What’s especially clever about this invention is how it turns a hard problem—matching up parts of two different app versions—into a graph problem. By using graphs, hashing, and smart matching, it can see through the noise caused by pointers and focus on the real changes. This means much smaller updates, faster downloads, and happier users.

Let’s recap the key innovations:

First, the use of directed acyclic graphs to show the structure and references in app files. This lets the system see the true layout of the app, not just the raw data.

Second, the matching algorithm that uses iterative hashing to pair up matching parts, even when their order has changed. This is a big step beyond old patching tools, which can’t handle lots of pointers.

Third, the use of control files with step functions to describe changes to references in a compact way. This turns what used to be a big, noisy list of changes into a small, clean set of instructions.

Fourth, the two-stage patching process: first, update the references to match the new app as closely as possible; second, use a standard patch tool to handle the remaining real changes.

And last, the flexibility to work on many types of devices, with the ability to save both data and storage space during updates.

All these pieces work together to make app updates smaller, faster, and smarter. The technology helps users keep their apps up to date without using too much data or storage. It helps developers deliver updates more often and with less hassle.

Conclusion

Updating apps is a part of our daily lives, but it doesn’t have to be a slow, painful process. This patent application shows a smarter way to handle updates by looking at how apps are really built. By using graphs and smart matching, it finds the real changes and ignores the noise caused by pointers and moved parts. The result is a faster, smaller update that saves data, storage, and time.

This approach stands out because it focuses on structure, not just data. It uses proven ideas from computer science—like graphs and hashing—to solve a real problem for millions of users. As apps get bigger and more complex, this kind of innovation will be key to keeping our devices fast, secure, and up-to-date.

If you are an app developer, a device maker, or just someone who wants faster updates, this technology offers a clear path forward. It turns a tough technical challenge into a smart, practical solution, making life easier for everyone who uses or manages apps.

Click here https://ppubs.uspto.gov/pubwebapp/ and search 20250217134.