Inventiv.org
  • Home
  • About
  • Resources
    • USPTO Pro Bono Program
    • Patent Guide
    • Press Release
  • Patent FAQs
    • IP Basics
    • Patent Basics
      • Patent Basics
      • Set up an Account with the USPTO
      • Need for a Patent Attorney or Agent
    • Provisional Patent Application
      • Provisional Patent Application
      • Provisional Builder
      • After you submit a PPA
    • Utility Patent Application
      • Utility Patent Application
      • File a Utility Patent Application
      • What Happens After Filing Utility Application?
    • Respond to Office Actions
    • Patent Issurance
  • ProvisionalBuilder
  • Login
  • Contact
  • Blogs
Inventiv.org
  • Home
  • About
  • Resources
    • USPTO Pro Bono Program
    • Patent Guide
    • Press Release
  • Patent FAQs
    • IP Basics
    • Patent Basics
      • Patent Basics
      • Set up an Account with the USPTO
      • Need for a Patent Attorney or Agent
    • Provisional Patent Application
      • Provisional Patent Application
      • Provisional Builder
      • After you submit a PPA
    • Utility Patent Application
      • Utility Patent Application
      • File a Utility Patent Application
      • What Happens After Filing Utility Application?
    • Respond to Office Actions
    • Patent Issurance
  • ProvisionalBuilder
  • Login
  • Contact
  • Blogs

MULTIPLE SIMULTANEOUS CODE DEBUGGING

Inventiv.org
July 22, 2025
Software

Invented by ELBAZ; Lior, PERELMAN; Vladimir, BEN DAVID; Meital

Debugging is a daily task for software developers. But what happens when you need to compare and debug two or more versions of your app at the same time? Today, we’ll explore a new patent-pending method that makes this possible—and much easier than before. This article will help you understand how this synchronized debugging works, why it matters, and what sets it apart from old ways of doing things.

Background and Market Context

Modern software moves fast. Teams add features, fix bugs, and experiment with new ideas every day. To keep track of all these changes, developers use version control systems like Git. These systems let you keep different versions of your code in separate “branches.” One branch might be the main product, another might be for testing a new feature, and another could be for fixing a bug.

With all these branches, it’s common to need to look at two or more versions of your app at the same time. Maybe you found a bug in the main branch, but it doesn’t happen in your new feature branch. Or maybe a new feature works in testing, but not when merged with the main code. To solve these problems, you need to compare how each version behaves while running the program. This process is called debugging.

Until now, debugging two versions at once was hard. Most tools only let you debug one program at a time. If you wanted to compare two versions, you might open two debugger windows side by side. You’d then run each version separately, trying to keep them in sync by hand. This is not easy. You have to remember where you are in each, switch back and forth, and hope you don’t lose your place. It eats up your computer’s memory and your time. Even worse, it’s easy to make mistakes and miss the root cause of a problem.

Some people try to debug one version first, write down what they find, and then debug the next version later. But this means you have to remember lots of details and can’t compare things side by side. If you want to change something in the first version after looking at the second, you have to start over. All this makes debugging across versions slow and error-prone.

As software gets more complex and teams work faster, the need for better debugging grows. Companies want to find and fix problems quickly. They want tools that keep up with the pace of development. That’s why a new way to debug more than one version at the same time—while keeping them in sync—is so important.

Scientific Rationale and Prior Art

Why has debugging across versions been so tough? The main reason is that most existing tools were built to work with only one running program. Even when a debugger can handle more than one process, it usually expects those processes to be different programs, not different versions of the same software.

When debugging two versions, you want to “step” through code at the same spot in each. For example, if you’re on line 20 in version A, you want to be at the matching spot in version B—even if that line is now line 22 because some code was added. Or if a function has been renamed or moved, you want to follow along in both. This is called finding “corresponding points of execution.” Old tools don’t do this. If you run two debuggers at once, you have to keep track of where you are in each version by yourself. If you step in one, nothing happens in the other. If you hit a breakpoint in one, you have to set it manually in the other and hope it matches up.

There have been some tools that try to help, but they don’t solve the core problem. Some let you do a “diff” of the source code to see what’s changed. That’s helpful for reading, but doesn’t help when the code is running. Others let you compare two sets of program outputs, but not step through code in sync. Some advanced debuggers can attach to multiple processes, but they don’t know that those processes are different versions of the same app. They can’t match up steps, breakpoints, or variable names that have changed.

One big challenge is that code changes over time. Functions get renamed. Lines move. Sometimes code is split into new functions, or combined. Even if the code looks similar, it might be in a different spot, or use different names. Sometimes, even if the source code is the same, the compiled program is different because of changes elsewhere in the codebase or toolchain. All these changes make it hard for a debugger to keep two versions in sync.

Another challenge is evaluating expressions. When you pause the program and want to check the value of “X,” that variable might be called something different in the other version. Or maybe it was moved into another function. Old debuggers don’t know about these changes, so you have to remember or figure them out by hand.

Because of all these hurdles, the standard way to debug across versions has been manual, slow, and not very accurate. There has been no simple, integrated way to sync up different versions, step them together, and see their differences in real time.

The new method described in this patent addresses these problems head-on. It brings a synchronized, automated way to debug two or more versions at the same time. It matches up corresponding points—even when code has changed—and makes it easy to set breakpoints, step through code, and evaluate variables in both versions at once. It also highlights the differences, so you can spot where things diverge, which is often where bugs hide.

Invention Description and Key Innovations

Let’s break down how this new debugging method works and what makes it different from old ways.

At its heart, the invention is a method and system for “synchronized debugging” of multiple versions of a software application. Here’s how it helps developers:

First, the debugger can receive a special command called a “synchronized debug command.” This is like telling the debugger, “Step both versions to the same place,” or, “Set a breakpoint at the matching place in both versions.” The tool figures out where that place is in each version, even if the code has changed or moved. Then, it applies the right debug actions to each version, keeping them in sync.

For example, let’s say you want to step into a function. In version A, that function might be on line 12, but in version B, it might be on line 16 because some new lines were added. The debugger matches up these spots, so when you step in both, you’re really stepping into the same logical place in the code, even if the lines are different.

The tool does this by comparing both the source code and the compiled program (“binary”). By looking at both, it can find where functions or variables have been renamed, moved, or changed. It also catches when the compiled code is different, even if the source code looks the same, because of changes elsewhere.

Here’s how it works in practice:

You start by picking which versions you want to debug—maybe the “main” branch and a “feature” branch. The debugger launches both versions at once. It can pause both at the same logical starting point, like the entry to the main function.

When you give a synchronized command (like “step”), the debugger figures out where to step in each version so that both reach matching code. If the code flows are slightly different—for example, one version has an extra function call—the debugger can step one version more times until both reach the next matching spot.

If you want to set a breakpoint, the debugger can map the target location in one version to the right place in the other version, based on code comparisons. This makes sure you’re always looking at the same logic in both versions.

The debugger also lets you evaluate expressions—like checking the value of a variable—at the same spot in both versions. If variable names have changed, it automatically maps the name from one version to the other. So if “count” in version A was changed to “total” in version B, you can still check the value in both without having to remember the new name.

A key part of the invention is how it finds these matching points. It uses both source code comparison (like looking for differences in text) and binary comparison (looking for matching compiled code). This way, it can find matches even when code looks different on the surface, or when changes elsewhere affect the compiled program.

The system also helps you see when and where the two versions start to behave differently. If the code paths diverge, the debugger can highlight this visually and ask you where to go next. You can pick new matching points, or let the tool suggest them.

The invention is flexible. It works with any programming language, any platform, and any number of versions. It’s not limited to a single operating system or type of code. It works with both compiled and interpreted languages. For interpreted languages that don’t have binaries, it just uses the source code comparison.

Here are a few more neat features:

– Visual highlighting of matching code points and differences, making it easy to follow along.
– Automatic handling of function and variable renaming, so you don’t have to remember what changed.
– Support for complex code changes, like moving code between functions or files. The tool can still find logical matches.
– When no match can be found, the debugger can ask you to pick the spot yourself.
– Multiple views, like call stacks and watch windows, for each version, so you can see what’s happening in both at once.
– Works with pre-built binaries or can build from source as needed.

From a technical point of view, the invention includes methods, systems, and computer-readable storage that carry out all these steps. The claims cover how commands are received, how matching points are found, how debug actions are applied in sync or separately, and how data is shown to the user. The system can even suggest matching points when functions are added, removed, or restructured.

By making it easy to debug multiple versions in sync, this invention saves time, reduces mistakes, and helps developers find the root cause of bugs much faster. It also helps teams keep their code healthy as they move quickly and make changes across many branches.

Conclusion

Debugging across different versions of software has always been a challenge. Old tools forced developers to juggle multiple windows, remember tiny details, and do lots of manual work. The new method described here changes the game. With synchronized debugging, you can see how different versions behave, step through code together, and spot problems faster—all in one place. It’s smart enough to find matching spots in the code, even as names change or code moves around. This makes debugging faster, easier, and less stressful.

If you work on software that changes often, or if you need to keep several branches healthy at once, this new way of debugging could save you hours of work and lots of frustration. As software keeps getting more complex, tools like this will be key to keeping up and shipping quality products. Synchronized debugging is a big step toward making development smoother and more reliable for everyone.

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

Tags: Microsoft Patent Review
Previous Story
METHOD AND APPARATUS WITH TILE-BASED IMAGE RENDERING
Next Story
ADAPTIVE ENCODING OF IMAGE REGIONS FOR MACHINE LEARNING AND AI APPLICATIONS

Related Articles

PHOTONIC INTEGRATED CIRCUITS WITH SUBSTRATE NOISE COUPLING MITIGATION

Invented by Wang; Zhechao, Vazimali; Milad Gholipour, Liu; Qing Photonic...

RESAMPLER FOR ELECTRONIC DISPLAY HAVING MULTIPLE PIXEL LAYOUTS

Invented by Boo; Hyun H., Miscuglio; Mario, Hu; Jenny, Guan;...

Menu

  • Home
  • About
  • Resources
    • USPTO Pro Bono Program
    • Patent Guide
    • Press Release
  • Patent FAQs
    • IP Basics
    • Patent Basics
      • Patent Basics
      • Set up an Account with the USPTO
      • Need for a Patent Attorney or Agent
    • Provisional Patent Application
      • Provisional Patent Application
      • Provisional Builder
      • After you submit a PPA
    • Utility Patent Application
      • Utility Patent Application
      • File a Utility Patent Application
      • What Happens After Filing Utility Application?
    • Respond to Office Actions
    • Patent Issurance
  • ProvisionalBuilder
  • Login
  • Contact
  • Blogs

Disclaimer Communications between you and Inventiv Foundation are protected by our Privacy Policy but not by the attorney-client privilege or as work product. Inventiv Foundation, Inc. can connect you to independent attorneys and self-help services at your specific direction. We are not a law firm or a substitute for an attorney or law firm. We cannot provide any kind of advice, explanation, opinion, or recommendation about possible legal rights, remedies, defenses, options, selection of forms or strategies. Your access to the website is subject to our Terms of Use.

Tags

Alphabet Amazon Facebook/Meta Microsoft Patent Review Samsung
  • Home
  • About
  • Inventiv’s Daily
  • Inventiv Cloud
  • Blogs
  • Contact
Inventiv.org
  • Home
  • About
  • Resources
    • USPTO Pro Bono Program
    • Patent Guide
    • Press Release
  • Patent FAQs
    • IP Basics
    • Patent Basics
      • Patent Basics
      • Set up an Account with the USPTO
      • Need for a Patent Attorney or Agent
    • Provisional Patent Application
      • Provisional Patent Application
      • Provisional Builder
      • After you submit a PPA
    • Utility Patent Application
      • Utility Patent Application
      • File a Utility Patent Application
      • What Happens After Filing Utility Application?
    • Respond to Office Actions
    • Patent Issurance
  • ProvisionalBuilder
  • Login
  • Contact
  • Blogs
Inventiv.org
  • Home
  • About
  • Resources
    • USPTO Pro Bono Program
    • Patent Guide
    • Press Release
  • Patent FAQs
    • IP Basics
    • Patent Basics
      • Patent Basics
      • Set up an Account with the USPTO
      • Need for a Patent Attorney or Agent
    • Provisional Patent Application
      • Provisional Patent Application
      • Provisional Builder
      • After you submit a PPA
    • Utility Patent Application
      • Utility Patent Application
      • File a Utility Patent Application
      • What Happens After Filing Utility Application?
    • Respond to Office Actions
    • Patent Issurance
  • ProvisionalBuilder
  • Login
  • Contact
  • Blogs