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

Seamlessly Transition Network Traffic to SDN Without Data Loss for Cloud and Enterprise IT

Inventiv.org
November 21, 2025
Apple

Invented by Narsian; Anish Sagar, Deng; Tao

Cloud computing is everywhere today. So are virtual networks and physical hardware. But connecting all these pieces smoothly is not always easy. This article will help you understand a new way to move network traffic from one system to another with almost no data loss. If you manage networks or work with cloud computing, this will show you how the latest patent-pending process can help you get the best of both worlds.

Your browser does not support the video tag.

Background and Market Context

Businesses today rely on both cloud services and physical, custom-built machines. Cloud services offer flexibility, speed, and savings. But sometimes you need the raw power or special features of real, physical hardware. These machines are called “bare-metal” devices. They are not shared with anyone else. You control every part of them.

The real magic happens when you combine cloud networks with bare-metal devices. Imagine you run a business that needs to process lots of data, very quickly. You want to use cloud virtual machines for most things, but you also want a custom-built server for special jobs—like heavy data crunching or ultra-fast storage. You want these two worlds to work together seamlessly, as if they are in the same room, even if they are far apart.

This is not just about convenience. When companies can mix and match cloud and bare-metal, they get the best of both. They can:
– Save money by only using physical servers where they really help.
– Scale up or down quickly using the cloud.
– Keep control over special hardware for sensitive or demanding tasks.
– Stay flexible as their needs change.

But there is a challenge. Cloud networks use software to define how devices connect and talk to each other. This is called Software Defined Networking (SDN). SDN lets you control who can talk to whom, watch for security threats, and make changes quickly—just by changing software settings, not plugging in cables. Cloud virtual machines understand SDN. Bare-metal devices, though, often do not. They cannot run the same software pieces that enforce these network rules.

So, how do you bring bare-metal devices into the world of SDN? The answer, until now, has been to use a “VXLAN switch.” This switch helps connect the bare-metal device to the virtual network. But it does not support all the SDN rules. That means some features or policies just do not work. It also makes it tricky when you want to move your network traffic from the old way (using the VXLAN switch) to the new way (using SDN appliances). If you do this move badly, you might lose data, drop connections, or create security gaps.

This is where the new patent application comes in. It describes a process for moving network traffic from the old system to the new one, smoothly and with almost no lost data. This is a big step forward for anyone who needs both cloud and custom hardware to work together—fast, safe, and with less headache.

Scientific Rationale and Prior Art

To really appreciate this invention, let’s look at how things worked before and why they needed to change. In the old days, if you wanted a virtual machine or a physical server to talk to another device, you set up the right cables and switches. Each device followed its own rules and you managed security and routing at each step. But as networks grew, this became too slow and too risky. Enter SDN.

SDN lets you control the network using software. Imagine having a dashboard where you can say, “This server can talk to that server, but not to this one,” or, “Let’s block this kind of traffic,” or, “Let’s make sure this application always gets enough bandwidth.” You do all this with a few clicks or lines of code. It is like switching from driving an old manual car to a smart car with auto-drive and lots of safety features.

Cloud virtual machines are built for SDN. They use special software pieces, called “network agents,” to follow all your SDN rules. But bare-metal devices can’t run these agents. They can’t enforce SDN rules directly. Instead, you had to rely on the VXLAN switch. The VXLAN switch acts like a bridge, letting bare-metal devices join the virtual network. But it is a simple bridge. It can’t enforce all the SDN policies—like blocking certain traffic, monitoring for threats, or shaping traffic for better performance.

To fix this, cloud providers started using SDN appliances. These are special devices (sometimes software, sometimes hardware) that hold all the SDN policies for the bare-metal server. The SDN appliance makes sure all the rules are followed, even if the bare-metal device can’t do it itself. It sits between the bare-metal device and the rest of the network, watching and controlling all the traffic.

The tricky part comes when you want to switch from the old system (bare-metal device connected through VXLAN switch) to the new one (bare-metal device traffic flowing through SDN appliance). If you just flip the switch, you might lose data. Some packets might get lost. Some connections might break. This is a big problem for businesses that need to stay online all the time—like banks, online stores, or health systems. Even a small hiccup can mean lost money or lost trust.

Before this invention, the way to handle the transition was clunky. You might try to set up both systems at once, but that could cause confusion (devices not knowing which route to use), or you might try to do it at a quiet time and hope for the best. There was no smooth, safe, automatic way to migrate network traffic and policies from VXLAN switch to SDN appliance, especially with minimal data loss.

Other attempts to solve this problem included complex scripts, manual changes, or waiting for all current connections to end before making the switch. None of these were ideal. They were slow, risky, and could not guarantee that no data would be lost.

This is why the new solution stands out. It gives a clear, step-by-step way to move traffic and policies from the old system to the new one without dropping packets or breaking connections. It uses a clever idea called an “interim shadow mapping policy” to help with the transition. This way, both the old and new routes work together for a short time, so that all traffic finds its way with no interruptions.

Invention Description and Key Innovations

Now, let’s break down how this new invention actually works and what makes it special. The goal is to move network traffic from the old path (bare-metal device through VXLAN switch) to the new path (traffic through SDN appliance), smoothly and safely. Here’s how it’s done, in simple terms:

1. Receiving the Migration Request: The process starts when someone (or some system) asks to move network traffic between a virtual network device and a bare-metal device, using the SDN appliance. The system checks the current setup: the virtual device is still connected directly to the VXLAN switch, which is linked to the bare-metal device.

2. Installing an Interim Shadow Mapping Policy: Before making any changes, the system puts a temporary “shadow” policy on the virtual network device. This policy tells the virtual device, “You can now accept traffic from the SDN appliance, but keep sending your own traffic to the VXLAN switch as before.” It’s like opening a new door for traffic coming in, but not yet changing where outgoing traffic goes. This makes sure that, if any packets start coming from the SDN appliance, the virtual device will know what to do with them. No packets get dropped just because they come from an unexpected place.

3. Redirecting Traffic at the VXLAN Switch: Next, the system tells the VXLAN switch to start sending all outgoing traffic (from the bare-metal device) to the SDN appliance instead of sending it straight to the virtual network device. Now, the SDN appliance is in the middle, able to enforce all the needed policies on this traffic.

4. Updating the Mapping Policy: Once the SDN appliance is handling outgoing traffic, the system updates the main mapping policy on the virtual network device. Now, when the virtual device wants to talk to the bare-metal device, it sends all its traffic to the SDN appliance, not to the VXLAN switch. The SDN appliance can now watch, shape, and secure all traffic in both directions.

This approach is clever because it lets both the old and new paths exist together for a short time. This overlap means existing connections do not break, and packets do not get lost. Once the SDN appliance is fully in charge, the system can safely remove the old connections and the temporary shadow policies.

Let’s look at some of the key features and benefits of this invention:

Minimal Data Loss: Because the shadow mapping policy is installed first, there is always a known route for every packet. Even if a packet arrives from a new direction (the SDN appliance), the virtual device is ready to handle it. This keeps data loss near zero.

Transparent to Applications: The process is designed so that customer applications (the programs running on the cloud or bare-metal devices) do not notice any change. There is no need to pause, restart, or reconfigure them. The network migration is invisible to them, which is important for uptime and reliability.

Orderly Transition: The steps are done in a specific order: first install the shadow policy, then redirect traffic, then update the main policy, and finally clean up. This order prevents confusion and makes sure that no packet is left with nowhere to go. If you did these steps in the wrong order, you could drop packets or break sessions.

Policy Enforcement: Once the SDN appliance is in the middle, it can enforce all the network policies that the bare-metal device could not do by itself. This means better security, better control, and more features—just like the rest of the cloud network.

Automation-Ready: The whole process can be automated. This is important for big networks, where manual changes are slow and error-prone. The invention can be built into scripts or management tools so that migrations happen smoothly, anytime they’re needed.

Scalability: The method works for one device or many. You can have lots of virtual machines and many bare-metal devices, all moving to the new SDN appliance-based network without trouble.

In more detail, the claims of the patent describe how the process works whether you use a method, a computer system, or a software product. The invention covers how to set up, manage, and remove the different mappings and policies as traffic is moved from one path to another. It also covers enforcing network rules on all traffic, no matter where it comes from.

One especially smart part is the “interim shadow mapping policy.” This is a temporary rule that lets the virtual device accept packets from the SDN appliance, even before the main switch happens. It’s like putting up a sign that says, “This way is open now!” so packets don’t get lost in the move. Once the migration is complete, the shadow mapping policy is removed, leaving only the new, clean setup.

The invention also thinks ahead about removing the old direct connections, cleaning up after itself so there are no leftover routes that could cause confusion or security risks.

All of this is done in a way that works with common cloud and networking technologies—virtual machines, VXLAN switches, SDN appliances, and bare-metal devices. It can fit into almost any modern data center or cloud setup.

Conclusion

This new way of moving network traffic between cloud virtual devices and bare-metal hardware is a game-changer. It solves a real problem for businesses that want the power of custom hardware together with the flexibility and security of the cloud. By using smart, temporary policies and a clear order of steps, it lets you switch from old to new without dropping data or breaking connections.

If you manage a cloud network, work with hybrid setups, or worry about uptime and security, this invention gives you a safe, simple, and automated way to make your network future-ready. You don’t have to choose between flexibility and control—you can have both, without the pain of complicated manual migrations.

As more companies mix cloud and bare-metal resources, solutions like this will become the new normal. They make it easier to grow, easier to change, and easier to keep your business running smooth, no matter how your needs evolve. That’s the promise of seamless, software-defined networking—now within everyone’s reach.

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

Tags: Patent Review
Previous Story
AI-Powered Voice Assistant Streamlines Diabetes Medication Management for Better Patient Outcomes
Next Story
AI-Driven System Enables Faster, Remote Issue Resolution for Enterprise Computers Using Live Data Analysis

Related Articles

AI-Driven Platform Automatically Builds Custom APIs to Streamline Business Integration and Performance

Invented by Hursh; Daniel Ray, Narkier; Sheppard David APIs are...

Advanced Battery Material Boosts Rechargeable Lithium-Ion Performance for Electric Vehicles and Devices

Invented by KIM; Young-Ki, CHOI; Aram, KIM; Sangmi, DOO; Sungwook,...

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