US 7519814

Analysis of U.S. Patent 7,519,814: System for Containerization of Application Sets

Date of Analysis: April 26, 2026

This report provides a summary of U.S. Patent No. 7,519,814, including its key bibliographic details and a plain-language explanation of its independent claims. The patent has recently been the subject of legal proceedings.

Bibliographic Information:

• Title: System for containerization of application sets
• Assignee: The current assignee is listed as Virtamove Corp. The original assignee was Trigence Corp.
• Inventors: Donn Rochette, Paul O'Leary, Dean Huffman
• Filing Date: September 13, 2004
• Issue Date: April 14, 2009
• Abstract: "A system is disclosed having servers with operating systems that may differ, operating in disparate computing environments, wherein each server includes a processor and an operating system including a kernel a set of associated local system files compatible with the processor. This invention discloses a method of providing at least some of the servers in the system with secure, executable, applications related to a service, wherein the applications may be executed in a secure environment, wherein the applications each include an object executable by at least some of the different operating systems for performing a task related to the service. The method of this invention requires storing in memory accessible to at least some of the servers a plurality of secure containers of application software. Each container includes one or more of the executable applications and a set of associated system files required to execute the one or more applications, for use with a local kernel residing permanently on one of the servers. The set of associated system files are compatible with a local kernel of at least some of the plurality of different operating systems. The containers of application software exclude a kernel; and some or all of the associated system files within a container stored in memory are utilized in place of the associated local system files resident on the server."

Legal Status and Recent Proceedings:

The patent is currently active. In January 2026, the U.S. Court of Appeals for the Federal Circuit (CAFC) denied a petition from Google LLC that challenged the validity of this patent. This ruling upheld a prior decision by the U.S. Patent and Trademark Office (USPTO), which had denied Google's request for an inter partes review (IPR), citing the "strong settled expectations" for a patent that has been in force for over 14 years. The case is identified in CAFC dockets as 26-111.

Plain-Language Overview of Independent Claims

U.S. Patent 7,519,814 has two independent claims. Below is a simplified explanation of the core concepts they protect.

Independent Claim 1:

This claim describes a method for running software applications securely on multiple servers, even if those servers have different operating systems. The core idea is to package an application, along with all the specific system files (like libraries and configuration files) it needs to run, into a "secure container."

Key steps of this method are:

• Storing multiple "secure containers" in a memory location accessible by the servers.
• Each container holds one or more applications and the necessary system files, but importantly, it does not include its own operating system kernel.
• When an application in a container runs on a server, it uses the server's own resident kernel to execute.
• The system files inside the container are used instead of the server's own local system files. This prevents conflicts, allowing different applications in different containers to use different versions of system files on the same machine without interfering with each other or the underlying operating system.

In essence, claim 1 protects a method of creating portable, isolated application environments that share the host server's core operating system kernel but bring their own specific dependencies with them.

Independent Claim 2:

This claim describes the system itself, rather than the method. It outlines a computer system designed to perform tasks using these secure containers.

The key components of this system are:

• A collection of "secure stored containers" that are accessible to one or more servers.
• Each container is isolated and self-contained ("mutually exclusive"), meaning its internal files cannot be shared with other containers.
• Each container is given its own unique identity on the network, such as its own IP address, host name, or MAC address.
• Like the method in claim 1, each container includes applications and their necessary system files but lacks its own kernel, instead relying on the server's underlying operating system kernel.
• The system includes a "run time module" that monitors "system calls" (requests from an application to the operating system's kernel). This module controls the applications, for example, by providing the container's unique identity information to the application instead of the server's actual identity, a process the patent refers to as "spoofing."

In short, claim 2 protects the architecture of a system that manages and runs these kernel-less, isolated application containers, giving each its own unique network identity and controlling its interaction with the host operating system.

As of April 26, 2026, US Patent 7,519,814 B2, titled "System for containerization of application sets," has been the subject of multiple litigation proceedings, including infringement lawsuits and a challenge to its validity at the Patent Trial and Appeal Board (PTAB). The patent's current assignee, Virtamove Corp. (formerly Appzero Software Corp.), has asserted its rights against several major technology companies.

Here is a summary of the known litigation involving US Patent 7,519,814:

District Court Litigation

1. Virtamove Corp. v. International Business Machines Corp. (IBM) & Hewlett Packard Enterprise Co. (HPE)

• Plaintiff: Virtamove Corp.
• Defendants: International Business Machines Corp.; Hewlett Packard Enterprise Co.
• Jurisdiction: U.S. District Court for the Eastern District of Texas
• Case Number: 2:24-cv-00093 (Initial case possibly consolidated)
• Filing Date: Early 2024.
• Status/Outcome: The lawsuits against IBM and HPE were consolidated in April 2024. As of October 14, 2025, Virtamove and IBM were in the process of finalizing a settlement. A second lawsuit was filed by Virtamove against IBM in the Eastern District of Texas under case number 2:25-cv-00619.

2. Virtamove Corp. v. Google LLC

• Plaintiff: Virtamove Corp.
• Defendant: Google LLC
• Jurisdiction: Initially filed in the U.S. District Court for the Western District of Texas, then transferred to the U.S. District Court for the Northern District of California.
• Case Number: 5:25-cv-00860 (in N.D. Cal.).
• Filing Date: January 31, 2024 (in W.D. Tex.).
• Status/Outcome: On November 28, 2025, the Northern District of California court partially granted Google's motion to dismiss, dismissing claims of induced and contributory infringement. However, the central claim of direct infringement survived.

3. Virtamove Corp. v. Amazon.com Inc.

• Plaintiff: Virtamove Corp.
• Defendant: Amazon.com Inc.
• Jurisdiction: U.S. District Court for the Eastern District of Texas (subject to a potential transfer).
• Case Number: Information not fully available in the provided results.
• Filing Date: 2024.
• Status/Outcome: Virtamove indicated its intent to petition the Federal Circuit to reverse a convenience transfer of this case, similar to its action in the Google case.

4. Virtamove Corp. v. Oracle Corp.

• Plaintiff: Virtamove Corp.
• Defendant: Oracle Corp.
• Jurisdiction: Likely a U.S. District Court.
• Case Number: Information not available in the provided results.
• Filing Date: Mentioned in a report from October 2025.
• Status/Outcome: Ongoing.

5. Virtamove Corp. v. [Microsoft Corp.](/litigations/by-defendant/Microsoft%20Corp.)

• Plaintiff: Virtamove Corp.
• Defendant: Microsoft Corp.
• Jurisdiction: U.S. District Court.
• Case Number: Information not available.
• Filing Date: December 2024.
• Status/Outcome: Ongoing.

6. Red Hat, Inc. v. Virtamove, Corp.

• Plaintiff: Red Hat, Inc. (subsidiary of IBM)
• Defendant: Virtamove, Corp.
• Jurisdiction: U.S. District Court for the Northern District of California
• Case Number: 5:24-cv-04740-PCP.
• Filing Date: August 2024.
• Status/Outcome: On April 21, 2025, the court granted Virtamove's motion to dismiss for lack of subject matter jurisdiction. Red Hat had sought a declaratory judgment that its technology did not infringe the '814 patent.

Patent Trial and Appeal Board (PTAB) & Federal Circuit

1. Google LLC v. Virtamove, Corp. (IPR)

• Petitioner: Google LLC
• Patent Owner: Virtamove, Corp.
• Jurisdiction: Patent Trial and Appeal Board (PTAB)
• Case Number: IPR2025-00487.
• Filing Date: January 30, 2025.
• Status/Outcome: Google filed a petition for Inter Partes Review to challenge the validity of the '814 patent. This led to an appeal at the Federal Circuit.

2. Google LLC v. Virtamove, Corp. (Federal Circuit Appeal)

• Appellant: Google LLC
• Appellee: Virtamove, Corp.
• Jurisdiction: U.S. Court of Appeals for the Federal Circuit
• Case Number: 26-111.
• Filing Date: Late 2025.
• Status/Outcome: On January 27, 2026, the Federal Circuit denied Google's petition, upholding the patent's validity against Google's challenge. This decision strengthens Virtamove's position in its ongoing infringement litigation.

Proceedings Overview

Four Inter Partes Review (IPR) proceedings have been filed against U.S. Patent No. 7,519,814 by a single petitioner, all of which were discretionarily denied institution by the Patent Trial and Appeal Board (PTAB). Consequently, no claims have been invalidated or sustained by the PTAB, leaving the patent un-hardened by a trial on the merits but signaling that the patent owner, Virtamove Corp., has been successful in defending the patent at the procedural stage.

---

IPR2025-01002 — Oracle Corporation v. Virtamove, Corp.

• Type: Inter Partes Review
• Filed: 2025-05-16
• Status: Discretionary Denial — The PTAB declined to institute a trial, meaning the petition was rejected on procedural grounds before any assessment of the merits of the invalidity arguments.
• Judge panel: Information not publicly available in summary data. Institution decisions are typically rendered by a panel of three Administrative Patent Judges (APJs).
• Petition grounds: The specific claims challenged and prior art asserted are not available in summary data but would be detailed in the IPR petition itself.
• Institution decision: The petition was denied institution on 2025-10-27. The "Discretionary Denial" status suggests the Board exercised its authority under 35 U.S.C. § 314(a) or § 325(d). A § 325(d) denial occurs when "the same or substantially the same prior art or arguments previously were presented to the Office," and the petitioner fails to show the original examiner made a material error. Given the extensive litigation history, a denial under the Fintiv framework, which considers parallel district court proceedings, is also a possibility.
• Final Written Decision: Not issued, as the IPR was not instituted.
• Settlement / termination: No settlement is indicated; the proceeding was terminated by the PTAB's denial.
• Appeal: Decisions not to institute an IPR are final and non-appealable to the Federal Circuit.
• Defensive value: This proceeding offers limited direct value for a defendant. The patent survived the challenge without a decision on the merits, and no estoppel attaches to the petitioner. However, the denial indicates the PTAB saw procedural reasons not to review the patent's validity, which could present hurdles for future petitioners, particularly if they rely on similar prior art or arguments.

IPR2025-01001 — Oracle Corporation v. Virtamove, Corp.

• Type: Inter Partes Review
• Filed: 2025-05-16
• Status: Discretionary Denial — The PTAB declined to institute a trial.
• Judge panel: Information not publicly available in summary data.
• Petition grounds: The specific claims and prior art asserted would be detailed in the IPR petition.
• Institution decision: The petition was denied institution on 2025-10-27. The reasoning is expected to be similar to the other petitions filed by Oracle on the same day against the same patent.
• Final Written Decision: Not issued.
• Settlement / termination: No settlement is indicated.
• Appeal: Not appealable.
• Defensive value: Similar to IPR2025-01002, this denial shows the patent owner's ability to procedurally defeat IPR challenges. It does not provide any substantive prior art analysis that a future defendant could use.

IPR2025-00965 — Oracle Corporation v. Virtamove, Corp.

• Type: Inter Partes Review
• Filed: 2025-05-16
• Status: Discretionary Denial — The PTAB declined to institute a trial.
• Judge panel: Information not publicly available in summary data.
• Petition grounds: The specific claims and prior art asserted would be detailed in the IPR petition.
• Institution decision: The petition was denied institution on 2025-10-27.
• Final Written Decision: Not issued.
• Settlement / termination: No settlement is indicated.
• Appeal: Not appealable.
• Defensive value: This result reinforces the pattern of successful procedural defenses by the patent owner. Any defendant considering an IPR would need to carefully analyze the basis for this denial to craft a petition that avoids a similar fate.

IPR2025-00964 — Oracle Corporation v. Virtamove, Corp.

• Type: Inter Partes Review
• Filed: 2025-05-16
• Status: Discretionary Denial — The PTAB declined to institute a trial.
• Judge panel: Information not publicly available in summary data.
• Petition grounds: The specific claims and prior art asserted would be detailed in the IPR petition.
• Institution decision: The petition was denied institution on 2025-10-27.
• Final Written Decision: Not issued.
• Settlement / termination: No settlement is indicated.
• Appeal: Not appealable.
• Defensive value: As with the other proceedings, this denial strengthens the patent's posture against procedural attacks at the PTAB but leaves its substantive validity untested in an AIA trial.

Strategic Summary

All claims of US Patent 7,519,814 remain UNTESTED on the merits by the PTAB. The four IPR petitions filed by Oracle Corporation were all terminated at the institution stage via discretionary denials. This outcome means no claims have been formally sustained or canceled through an IPR trial. While public data aggregators and the patent's own metadata show a much more extensive litigation and PTAB history, including settlements and other procedural terminations, the canonical proceedings for this analysis all ended without a merits review.

From an estoppel perspective, a defendant's position is not constrained by these specific outcomes. Because the PTAB did not institute trial, petitioner estoppel under 35 U.S.C. § 315(e) does not apply to Oracle or its real parties-in-interest. Therefore, Oracle is not barred from re-challenging the patent in district court or at the PTAB using the same or different grounds. However, any future petitioner, including a current defendant, who files an IPR with "the same or substantially the same prior art or arguments" would face a high bar under § 325(d). They would need to persuade the Board that the original patent examiner committed a material error, a difficult standard to meet.

The clear pattern is one of a single, well-funded petitioner (Oracle) filing a coordinated, multi-petition challenge against the patent, a common strategy to assert different invalidity theories. The uniform discretionary denials suggest the patent owner, Virtamove Corp., effectively argued that the petitions should be denied for procedural reasons—perhaps due to parallel litigation under the Fintiv factors or because the art was deemed cumulative to that already considered by the USPTO.

Recommended Next Steps

For a defendant currently facing assertion of US Patent 7,519,814, the key takeaway is that an invalidity defense at the PTAB may face significant procedural hurdles before the merits are even considered.

• Critically Analyze the Institution Decisions: A defendant must obtain and scrutinize the PTAB's Decisions to Deny Institution in IPR2025-01002, -01001, -00965, and -00964. The Board’s specific reasoning is paramount. If the denials were based on § 325(d) because the asserted prior art was duplicative of the examination record, a defendant would need to conduct a thorough search for new prior art that is materially different. If the denials were based on Fintiv due to co-pending litigation, a defendant would need to assess whether the litigation landscape has changed in a way that would now favor institution.

• Evaluate Other PTAB Proceedings: The patent's metadata indicates numerous other PTAB challenges, some of which were terminated due to settlement (e.g., IPR2025-00851, IPR2025-00852). Understanding the petitioners, timing, and outcomes of those proceedings is crucial for a complete defensive picture. While not part of the canonical list for this analysis, they provide important context about the patent owner's litigation and negotiation strategies.

• Consider Federal Circuit Activity: Public records indicate that Google LLC unsuccessfully challenged the patent, with the Federal Circuit denying its petition. A defendant should review the filings in that appeal to understand the arguments made and the court's disposition, as it may inform litigation strategy regarding claim construction or validity arguments that have already been vetted at the appellate level.

Since no PTAB proceedings are currently active, there are no immediate trial milestones to monitor. The defensive path forward requires a deep dive into the procedural history of these denied petitions to determine if any viable path remains for a PTAB challenge.

Inventors

• Donn Rochette
• Paul O'Leary
• Dean Huffman

All inventors were associated with the original assignee, Trigence Corp., at the time of the provisional application filing in September 2003.

Original assignee

The original assignee of US patent 7,519,814 was Trigence Corp.

Trigence Corp. developed virtualization technology designed to encapsulate applications and move them between servers. This technology was embodied in a product initially called "Trigence Application-in-a-Box" and later rebranded as AppZero. The company itself eventually changed its name to AppZero Corp. It appears the company shipped a product that embodied the claims of the patent. The company, after several name changes and assignments, is now known as Virtamove Corp. and appears to be operating.

Assignment timeline

• 2004-09-13 (executed) / recorded 2004-10-04 — Reel 015338/0393

  • Conveyance: Assignment of Assignors Interest
  • Assignor: Huffman, Dean; O'Leary, Paul; Rochette, Donn
  • Assignee: Trigence Corp.
  • Correspondent: Donald R. Boys, Central Coast Patent Agency, Inc., 3 Hangar Way Ste D, Watsonville, CA 95076
  • Context: Standard assignment of invention rights from the inventors to their employer.

• 2009-03-05 (executed) / recorded 2009-03-05 — Reel 022359/0569

  • Conveyance: Change of Name
  • Assignor: Trigence Corp.
  • Assignee: Appzero Corp.
  • Correspondent: Donald R. Boys, Central Coast Patent Agency, Inc., 3 Hangar Way Ste D, Watsonville, CA 95076 (recurring correspondent)
  • Context: A corporate name change from Trigence Corp. to Appzero Corp.

• 2010-10-06 (executed) / recorded 2010-10-06 — Reel 025095/0106

  • Conveyance: Assignment of Assignors Interest
  • Assignor: Appzero Corp.
  • Assignee: Appzerosoftware Corp.
  • Correspondent: Donald R. Boys, Central Coast Patent Agency, Inc., 3 Hangar Way Ste D, Watsonville, CA 95076 (recurring correspondent)
  • Context: Internal reorganization, transferring the patent to a differently named corporate entity.

• 2010-10-13 (executed) / recorded 2010-10-13 — Reel 025114/0971

  • Conveyance: Corrective Assignment
  • Assignor: Appzero Corp.
  • Assignee: Appzero Software Corp.
  • Correspondent: Donald R. Boys, Central Coast Patent Agency, Inc., 3 Hangar Way Ste D, Watsonville, CA 95076 (recurring correspondent)
  • Context: Correction of the assignee's name from the previous assignment.

• 2015-09-21 (executed) / recorded 2015-10-08 — Reel 036329/0146

  • Conveyance: Security Interest
  • Assignor: Appzero Software Corp.
  • Assignee: Comerica Bank
  • Correspondent: Robert M. Gielowski, Gielowski, Federick & Associates, PLLC, 2501 E. Beltline SE, Suite 210, Grand Rapids, MI 49546
  • Context: The patent was pledged as collateral to secure financing from Comerica Bank.

• 2018-09-21 (executed) / recorded 2018-09-25 — Reel 046938/0923

  • Conveyance: Release by Secured Party
  • Assignor: Comercia Bank [sic]
  • Assignee: Appzero Software Corp.
  • Correspondent: John S. Paniaguas, Clark Hill PLC, 151 S. Old Woodward, Suite 200, Birmingham, MI 48009
  • Context: Release of the security interest by the bank, returning full rights to Appzero Software Corp.

• 2018-09-27 (executed) / recorded 2018-09-27 — Reel 047029/0166

  • Conveyance: Corrective Assignment
  • Assignor: Comerica Bank
  • Assignee: Appzero Software Corp.
  • Correspondent: John S. Paniaguas, Clark Hill PLC, 151 S. Old Woodward, Suite 200, Birmingham, MI 48009 (recurring correspondent)
  • Context: Correction of the assignor's name ("Comercia Bank" to "Comerica Bank") from the release document.

• 2024-11-18 (executed) / recorded 2024-11-19 — Reel 074157/0192

  • Conveyance: Change of Name
  • Assignor: Appzero Software Corp.
  • Assignee: Virtamove Corp.
  • Correspondent: Appzero Software Corp., 1001 Massachusetts Avenue, Suite 2, Cambridge, MA 02138
  • Context: Another corporate name change, from Appzero Software Corp. to Virtamove Corp.

• 2024-12-12 (executed) / recorded 2024-12-12 — Reel 074465/0425

  • Conveyance: Corrective Assignment
  • Assignor: Comerica Bank
  • Assignee: Virtamove Corp. (formerly Appzero Software Corp.)
  • Correspondent: John S. Paniaguas, Clark Hill PLC, 151 S. Old Woodward Ave., Ste 200, Birmingham, MI 48009 (recurring correspondent)
  • Context: A corrective assignment to update the assignee name on the previous release of security interest to reflect the most recent name change.

Timeline diagram

timeline
    title Ownership of US 7519814
    2003 : Priority application filed
    2004 : Assigned to Trigence Corp
    2009 : Issued
         : Name change to Appzero Corp
    2010 : Assigned to Appzero Software Corp
         : Corrective assignment filed
    2015 : Security interest to Comerica Bank
    2018 : Security interest released
         : Corrective release filed
    2024 : Name change to Virtamove Corp
         : Corrective assignment filed

NPE / troll-pattern signals

1. Shell-entity transfer: Not present. The assignments have been between related operating companies (Trigence → AppZero → Virtamove) or for financing purposes (Comerica Bank). The current assignee, Virtamove Corp., appears to be an operating company.

2. Known asserter in the chain: Not present. None of the assignees (Trigence Corp., Appzero Corp., Appzero Software Corp., Comerica Bank, Virtamove Corp.) appear on standard lists of high-frequency patent asserters.

3. Repeat correspondent across the chain: Present. Donald R. Boys of Central Coast Patent Agency, Inc. handled the initial assignment and all subsequent transfers and name changes through 2010 (Reels 015338/0393, 022359/0569, 025095/0106, 025114/0971). John S. Paniaguas of Clark Hill PLC handled the release of the security interest and its subsequent corrections in 2018 and 2024 (Reels 046938/0923, 047029/0166, 074465/0425). The recurrence indicates a consistent relationship with counsel but does not, in this case, point to a known NPE attorney.

4. Cascading transfers: Not present. The transfers are separated by years and are primarily related to corporate name changes or financing events, not rapid, sequential transfers between shell LLCs.

5. Pre-litigation transfer: Present. According to litigation data from Unified Patents and Darts-ip, the first litigation involving this patent was filed in early 2024. The final corporate name change to Virtamove Corp. was executed on 2024-11-18 and recorded the next day. While this is a name change rather than a transfer to a third party, its timing just before recent litigation in 2024-2025 is noteworthy.

6. Bankruptcy fire-sale: Not present. There is no indication of bankruptcy proceedings in the assignment record.

7. Privateering: Not present. The chain of title remains within the same corporate family that developed the technology.

8. Defensive aggregator (anti-NPE): Not present. The patent has not been transferred to a known defensive aggregator.

Verdict

Operating-company assertion

The patent has remained with its originator, which has undergone several name changes (Trigence → AppZero → Virtamove). The assignment history shows a standard corporate evolution, including securing and releasing debt, rather than a transfer to a non-practicing entity for assertion. Virtamove Corp., the current assignee, appears to be an operating company continuing the business of the original inventor entity. The recent litigation in 2024 and 2025 is therefore best characterized as an operating company asserting its own patents.

A complete record of assignments for US Patent 7,519,814 can be viewed at the USPTO Patent Assignment Search.

Analysis of Prior Art Cited in U.S. Patent 7,519,814

This section details the prior art references cited by the examiner during the prosecution of U.S. Patent 7,519,814. For each reference, this analysis provides the citation, relevant dates, a brief description of the disclosed technology, and an assessment of which claims in the '814 patent it could potentially anticipate under 35 U.S.C. § 102.

The '814 patent has a priority date of September 15, 2003. Therefore, any reference published or filed before this date constitutes prior art.

---

1. U.S. Patent 5,944,781

• Full Citation: US Patent 5,944,781, "Method and system for providing an isolated computing environment within a computer system"
• Inventors: Murray, et al.
• Filing Date: June 25, 1997
• Publication (Issue) Date: August 31, 1999
• Brief Description: This patent describes a system for creating isolated computing environments, termed "virtual machines," on a single computer. Each virtual machine has its own set of resources, including a separate file system and network address, effectively isolating it from other virtual machines on the same host. It focuses on partitioning a single system to run multiple isolated environments concurrently, managed by a host operating system.
• Potential Anticipation of Claims:
  • Claim 1 & 2: This reference appears highly relevant. It discloses creating isolated environments for applications with their own files. The concept of providing a unique identity (like a network address) to an isolated environment is also present, which maps to the "unique identity" element of claim 2. However, the '814 patent specifically claims a "container" that excludes a kernel and utilizes the local kernel of the server. The key distinction would be whether Murray's "virtual machine" requires a full guest operating system, including its own kernel, for each isolated environment. The '814 patent's innovation lies in sharing the host kernel. If Murray's system necessitates a separate kernel for each partition, it would not fully anticipate the claims of the '814 patent.

2. U.S. Patent 6,078,924

• Full Citation: US Patent 6,078,924, "Firewall system for providing Internet service to a virtual private network"
• Inventors: Ainsworth
• Filing Date: June 10, 1997
• Publication (Issue) Date: June 20, 2000
• Brief Description: Ainsworth describes a firewall system that manages network traffic for virtual private networks (VPNs). It details methods for associating network policies and IP addresses with specific groups of users or applications to securely partition network access. The focus is on network-level isolation and security rather than application execution environments.
• Potential Anticipation of Claims:
  • Claim 2: This reference is relevant to the "unique identity" aspect of claim 2, particularly the association of a unique IP address with a set of applications. It teaches isolating network identities. However, it does not describe the core concept of the '814 patent: a kernel-less container that packages an application with its own set of system files to be used in place of the host's files. The Ainsworth patent is focused on network security policy and not on application virtualization or containerization. Therefore, it is unlikely to anticipate either claim 1 or the entirety of claim 2.

3. U.S. Patent 6,397,242 B1

• Full Citation: US Patent 6,397,242 B1, "Method for virtualizing resources in a computer system"
• Inventors: Devine, et al.
• Filing Date: October 29, 1999
• Publication (Issue) Date: May 28, 2002
• Brief Description: This patent, assigned to VMware, Inc., is a foundational text on virtual machine technology. It discloses a method where a virtual machine monitor (VMM) or "hypervisor" intercepts system calls and manages access to hardware resources for multiple guest operating systems. Each guest OS runs in its own isolated virtual machine and believes it has exclusive control over the hardware.
• Potential Anticipation of Claims:
  • Claim 1 & 2: This reference is a strong piece of prior art for the concept of virtualizing and isolating computer environments. The VMM's role in intercepting calls is analogous to the "run time module" in claim 2. However, the '814 patent explicitly distinguishes its invention from this type of virtual machine technology in its background section, stating, "The key difference between the Virtual Machine approach and the approach described herein is that in the former an operating system, including files and a kernel, must be deployed for each application while the latter only requires one operating system..." The '242 patent describes a system where each virtual machine requires its own full operating system, including a kernel. Because the claims of the '814 patent specifically recite that the container excludes a kernel, this reference does not directly anticipate them.

4. U.S. Patent Application Publication 2002/0188708 A1

• Full Citation: US 2002/0188708 A1, "System and method for supporting multiple isolated user environments on a single host computer"
• Inventors: Wookey, et al.
• Filing Date: June 14, 2001
• Publication Date: December 12, 2002
• Brief Description: This publication describes a system for hosting multiple "virtual environments" on a single server. It details a method for creating isolated file systems and process spaces for different applications or users. The system redirects file system calls from an application to a private, per-environment directory, effectively isolating its view of the file system. It also discusses managing unique identities for these environments.
• Potential Anticipation of Claims:
  • Claim 1 & 2: This reference is highly relevant and potentially the closest prior art. It teaches creating multiple isolated environments on a single host and providing each with a private file system view. The concept of redirecting system calls to achieve isolation is similar to the '814 patent's "run time module" that intercepts system calls. The crucial question for anticipation is whether Wookey's "virtual environment" is kernel-less and utilizes the host kernel, and whether it explicitly teaches packaging system files (like libraries) with the application for use in place of the host's system files. If Wookey's system provides this level of file system virtualization and shares the host kernel, it could be argued to anticipate key elements of both independent claims.

5. "A Multi-User, Secure UNIX" by J.P.L. Woodward

• Full Citation: Woodward, J.P.L. "A Multi-User, Secure UNIX." The Radio and Electronic Engineer, Vol. 52, No. 1, Jan. 1982.
• Publication Date: January 1982
• Brief Description: This academic paper discusses early methods for enhancing the security and isolation of multi-user UNIX systems. It explores techniques for restricting user access to files and system resources to prevent interference between different users on the same machine. The focus is on security hardening of a traditional time-sharing operating system.
• Potential Anticipation of Claims:
  • Claim 1 & 2: This reference describes the general goal of isolation but from a security perspective within a monolithic OS. It does not teach the concept of a portable, self-contained "container" that packages an application with its own specific system file dependencies and has its own unique network identity. The methods described are tied to the host operating system's user management and do not involve creating a virtualized, transportable application environment. Therefore, it is unlikely to anticipate the claims.

---

Summary of Prior Art Relevance:

The most relevant prior art references are U.S. Patent 5,944,781 (Murray) and U.S. Patent Application 2002/0188708 A1 (Wookey). Both disclose systems for creating isolated computing environments with private resources. The critical distinguishing feature of U.S. Patent 7,519,814 appears to be the specific claim limitation that the "container" is kernel-less and that the system files within the container are utilized in place of the host system's files, all while sharing the single host OS kernel. The VMware patent ('242) is explicitly distinguished by its reliance on a separate kernel for each virtual machine. The strength of the '814 patent against an anticipation challenge would hinge on whether prior art like Wookey's truly teaches this specific architectural approach to application virtualization, now commonly understood as OS-level virtualization or containerization.

Analysis of Obviousness for U.S. Patent 7,519,814

Date of Analysis: May 14, 2026
Patent: US 7,519,814 B2
Title: System for containerization of application sets
Priority Date: September 15, 2003

This analysis examines the obviousness of the independent claims of US Patent 7,519,814 in light of prior art existing before its priority date of September 15, 2003, pursuant to 35 U.S.C. § 103.

A Person Having Ordinary Skill in the Art (PHOSITA) at the time of the invention would be a systems administrator or operating systems developer with several years of experience in Unix-like operating systems (e.g., BSD, Linux, Solaris), including knowledge of system virtualization, application deployment, and network services management.

The claims of the '814 patent are rendered obvious by a combination of prior art technologies that were well-established and widely understood before the priority date. The primary teaching is found in FreeBSD Jails, first released with FreeBSD 4.0 on March 14, 2000. Secondary teachings related to system call interception and software packaging practices were also common knowledge.

Prior Art: FreeBSD Jails (Released March 2000)

FreeBSD Jails provided a robust form of operating system-level virtualization, a significant advancement over the older chroot utility. By 2003, a PHOSITA would have been aware of the following capabilities of FreeBSD Jails:

1. Filesystem and Process Isolation: A jail confines processes to a specific directory subtree, preventing them from accessing or affecting files and processes outside the jail. This directly teaches the concept of a "secure" and "mutually exclusive" environment as described in the '814 patent. Jails were created to establish a "clean, clear-cut separation" between services for security and ease of administration.
2. Kernel Sharing, Not Duplication: Processes within a jail run on the host system's single, shared kernel. This directly teaches the claimed invention's central feature of creating a "container" that "exclud[es] a kernel" and "utiliz[es] a kernel resident on the server."
3. Unique Network Identity: A key feature of FreeBSD Jails was the ability to assign a unique IP address to each jail. This provided network-level isolation, allowing multiple jails on one machine to run the same service (e.g., a web server on port 80) without conflict. This directly teaches the claim 2 limitation of providing each container with its "own unique identity associated therewith, said identity comprising at least one of an IP address."
4. Self-Contained Userland: To function, a jail required a complete set of userland files, including system libraries and configuration files, to be placed within its directory subtree. A PHOSITA would understand that to run an application inside a jail, all of its dependencies (executables, libraries, config files) must be present inside the jail's root path. This directly anticipates the concept of packaging an application with its "set of associated system files required to execute the one or more applications."

Combination of Prior Art and Motivation

A PHOSITA would have been motivated to combine the established features of FreeBSD Jails with other well-known techniques to arrive at the invention claimed in the '814 patent.

1. Combination of FreeBSD Jails and Standard Dependency Management

• Prior Art: FreeBSD Jails and the common practice of resolving application dependencies by co-locating required libraries and configuration files.
• Obviousness of Claim 1: Claim 1 describes packaging an application with its required "system files" into a container, where those files are used in place of the host's system files. A PHOSITA facing a common "dependency hell" problem—where two applications in different jails require different versions of a shared library—would find it obvious to solve this by simply copying the specific, required version of that library into each jail's respective file system. This was a standard procedure for making a chroot or jail environment functional. The motivation is direct: to make the application run correctly and be independent of the host's specific library versions. Combining this standard practice with the isolation provided by FreeBSD Jails directly yields the method described in Claim 1.

2. Combination of FreeBSD Jails and System Call Interposition

• Prior Art: FreeBSD Jails and the well-documented technique of "system call interposition" (also known as interception or tracing). System call interposition was a known method used for security, monitoring, and debugging applications before 2003. Tools and research papers explicitly discussed intercepting system calls to "monitor and regulate" an application's interactions with the operating system.
• Obviousness of Claim 2: Claim 2 adds the limitations of a unique identity (including hostname and MAC address) and a "run time module for monitoring system calls" to "provide control" over applications, a process the patent calls "spoofing."
  • Motivation: A PHOSITA seeking to enhance the isolation of a FreeBSD jail would recognize its limitations. While a jail could have its own IP address, it would still report the host system's hostname by default. To create a more complete virtual environment, an application inside the jail would need to see its own hostname.
  • The Obvious Solution: The most direct and well-known method to achieve this was to intercept the system call that requests the hostname (e.g., uname()) and return a custom, jail-specific value instead of the true kernel value. This technique of providing false, or "spoofed," information via an interposing module was a clear application of existing system call interception technology to solve a known limitation in jail-based virtualization. This directly teaches the "run time module" and its "spoofing" function as claimed. Extending this principle from hostname to other identifiers like a MAC address would be a trivial and obvious step for a PHOSITA.

Conclusion

The independent claims of US Patent 7,519,814 describe a system that is a logical and obvious combination of pre-existing technologies. FreeBSD Jails, publicly available and documented more than three years before the patent's priority date, taught the core concepts of an isolated, kernel-less environment with its own filesystem and unique IP address. The motivation to solve known problems, such as library version conflicts and incomplete environment virtualization (e.g., shared hostnames), would have led a PHOSITA to the obvious solutions of bundling specific application dependencies within the jail and using system call interposition to virtualize other system identifiers. Therefore, the claimed invention would have been obvious to a person having ordinary skill in the art at the time the invention was made.

Analysis of Patent Term, Adjustments, and Family for U.S. Patent 7,519,814

As of May 14, 2026, a detailed analysis of U.S. Patent 7,519,814, "System for containerization of application sets," reveals the following information regarding its term, related applications, and projected expiration.

Patent Term Adjustments (PTA) and Extensions (PTE):

• Patent Term Adjustment (PTA): There is no indication of any Patent Term Adjustment (PTA) granted for this patent. PTA is a process to extend a patent's term to account for delays caused by the USPTO during prosecution. The absence of such an adjustment suggests the patent's examination proceeded within the statutory timeframes.
• Patent Term Extension (PTE): There is no record of a Patent Term Extension (PTE). PTE is typically granted for patents covering products that undergo a lengthy regulatory review process, such as pharmaceuticals, which is not applicable to this technology.

Continuity and Related Applications:

The application for patent 7,519,814 (application number 10/939,903) claims priority from two U.S. provisional applications:

• 60/502,619: Filed on September 15, 2003
• 60/512,103: Filed on October 20, 2003

The patent itself is part of a larger family of related applications, indicating further development and refinement of the invention. The known related, non-provisional U.S. applications include:

• Continuation Applications:
  • U.S. Patent 7,774,762: Issued from application 11/380,285, filed on April 26, 2006.
  • U.S. Patent 7,757,291: Issued from application 11/432,843, filed on May 12, 2006.
  • U.S. Patent Application Publication 2008/0222160 A1: Published from application 12/075,842, filed on March 13, 2008.

There is no record of any divisional applications associated with the '814 patent.

Projected Expiration Date:

The standard term for a U.S. utility patent filed before June 8, 1995, is 17 years from the issue date or 20 years from the earliest non-provisional filing date, whichever is longer. For patents filed on or after that date, the term is 20 years from the earliest non-provisional application filing date.

For U.S. Patent 7,519,814:

• Filing Date: September 13, 2004
• Issue Date: April 14, 2009

The 20-year term is calculated from the filing date. However, public records indicate an adjusted expiration date of April 4, 2027. This suggests there may have been a terminal disclaimer or other adjustment affecting the term, though specific PTA calculations are not detailed in the available public information. The provided expiration date is consistent across multiple data sources.

Defensive Disclosure and Prior Art Derivations for Containerization Systems

Publication Date: May 14, 2026
Subject: Derivatives and obvious variations of technologies described in US Patent 7,519,814. This document is intended to enter the public domain as prior art.

---

Claim 1 Derivations: Variations on the Method of Containerization

Axis 1: Component & Architecture Substitution

1. Derivative: User-Space System Call Interception via Dynamic Binary Instrumentation

• Enabling Description: This method achieves application isolation without a kernel-mode "run time module." Instead, a user-space daemon pre-processes the application's executable binary before execution. It uses dynamic binary instrumentation (DBI) frameworks like PIN or Valgrind to inject interception logic directly into the application's process space at runtime. When the application makes a system call, the injected code executes first. This code can rewrite arguments or redirect calls to a user-space container management daemon that emulates the desired isolated environment (e.g., provides a container-specific hostname or redirects file access to a container image). This avoids the security risks and performance overhead of a custom kernel module and is portable across any kernel version that supports the underlying ptrace mechanism. The container filesystem is mounted via FUSE (Filesystem in Userspace), with the management daemon serving as the FUSE driver.

• Diagram:

  sequenceDiagram
      participant App as Application Process
      participant DBI as DBI Framework (in-process)
      participant MgmtDaemon as Container Management Daemon (user-space)
      participant Kernel
  
      App->>DBI: Makes syscall (e.g., uname())
      DBI->>MgmtDaemon: Intercepts call, forwards to Daemon
      Note over MgmtDaemon: Looks up container-specific hostname
      MgmtDaemon-->>DBI: Returns spoofed hostname
      DBI-->>App: Returns spoofed data to application
      Note over App: Application receives container identity, not host's
  

2. Derivative: Copy-on-Write (CoW) Layered Filesystems with Object Storage Backends

• Enabling Description: The "container" is not a monolithic collection of files but a set of layered, read-only filesystem images stored in a content-addressable object store (e.g., an S3-compatible system). When a container is instantiated, a union filesystem (like OverlayFS) is constructed. It layers a new, writable empty directory over the read-only base layers pulled from object storage. All writes from the application are captured in this top writable layer (the "copy-on-write" layer), which resides on local storage. The base images are immutable and can be shared and deduplicated across thousands of containers, drastically reducing storage footprint and container startup time, as only the writable layer needs to be created, not a full copy of all system files.

• Diagram:

  graph TD
      subgraph Container View
          A[Unified Mount Point: /]
      end
  
      subgraph Filesystem Layers
          B(Writable Layer <br/><i>Container-specific, ephemeral</i>)
          C(App Layer <br/><i>Read-only, from Object Store</i>)
          D(System Libs Layer <br/><i>Read-only, from Object Store</i>)
          E(Base OS Layer <br/><i>Read-only, from Object Store</i>)
      end
  
      B --OverlayFS--> A
      C --OverlayFS--> A
      D --OverlayFS--> A
      E --OverlayFS--> A
  
      F[Object Storage <br/><i>(e.g., Ceph, S3)</i>]
      F --pulls layers--> C
      F --pulls layers--> D
      F --pulls layers--> E
  

---

Axis 2: Operational Parameter Expansion

3. Derivative: Hard Real-Time Deterministic Containerization for Avionics

• Enabling Description: This system is designed for a real-time operating system (RTOS) with POSIX PSE53/ARINC 653 compliance. The "container" is a time-and-space partitioned execution environment. The "run time module" is a partitioning microkernel or hypervisor that enforces a fixed, cyclic execution schedule. Each container is allocated a specific time window (e.g., 20ms every 100ms cycle) on a specific CPU core. All memory is pre-allocated, and system calls for dynamic memory allocation are forbidden or strictly limited. The interceptor validates that system calls (e.g., for IPC) only target other processes within the same partition or approved ARINC 653 ports, ensuring a fault in a low-criticality container (e.g., cabin climate control) cannot impact a high-criticality one (e.g., flight guidance).

• Diagram:

  stateDiagram-v2
      direction LR
      [*] --> Core1_Execution
      
      state Core1_Execution {
          direction TB
          state "Container_A (20ms)" as C_A
          state "Container_B (50ms)" as C_B
          state "Kernel_Idle (30ms)" as K_I
          
          [*] --> C_A
          C_A --> C_B : Time window expires
          C_B --> K_I : Time window expires
          K_I --> C_A : Major frame cycle repeats
      }
  
      note right of Core1_Execution
          Major Frame: 100ms
          Container A: Flight Guidance (Critical)
          Container B: Navigation Display (Essential)
          Kernel Idle: System Maintenance
          The "run time module" is the cyclic scheduler.
      end note
  

---

Axis 3: Cross-Domain Application

4. Derivative: Containerized Genomic Analysis Pipelines in Bio-Informatics

• Enabling Description: A complex genomic sequencing and analysis workflow, consisting of multiple tools (e.g., BWA for alignment, GATK for variant calling), is packaged into a single "secure container." This container includes not just the specific versions of the executable tools but also all their specific dependencies (e.g., Python 2.7, specific R libraries, Samtools). This ensures that a pipeline developed in 2024 produces the exact same results when run on a different server in 2026, guaranteeing scientific reproducibility. The "run time module" intercepts system calls to redirect large data file I/O to a high-performance parallel filesystem (like Lustre or GPFS) and provides a unique identity that is used to tag all output data for provenance tracking.

• Diagram:

  flowchart TD
      subgraph Genomics Container
          A(bwa-mem) --BAM file--> B(samtools)
          B --Sorted BAM--> C(GATK HaplotypeCaller)
          C --VCF file--> D(Annotation Script)
      end
      
      subgraph Host System
          E(Container Runtime)
          F(Lustre Filesystem)
          G(Host Kernel)
      end
  
      E --manages--> Genomics Container
      A --write() syscall--> G
      B --write() syscall--> G
      C --write() syscall--> G
      D --write() syscall--> G
  
      G --intercepted by runtime--> F
      note on G: System call interceptor redirects all I/O from container to /lustre/job_id/
  

---

Axis 4: Integration with Emerging Tech

5. Derivative: AI-Optimized Resource Scheduling and Security Threat Detection

• Enabling Description: The "run time module" is extended with a machine learning inference engine (e.g., running a lightweight neural network). It continuously samples system call traces (call type, frequency, arguments, return values) from each container and feeds this data into two models.

  1. QoS Model: Predicts near-term CPU, memory, and I/O demand, dynamically adjusting the container's cgroup limits to proactively prevent resource starvation or contention between containers.
  2. Security Model: A pre-trained anomaly detection model identifies deviations from the container's normal system call pattern. If a deviation is detected (e.g., unexpected network connections, file access to /etc/shadow), the module can automatically quarantine the container by applying restrictive seccomp filters and network firewalls.

• Diagram:

  graph TD
      A[Container #1] --Syscall Trace--> B{Run Time Module};
      C[Container #2] --Syscall Trace--> B;
  
      subgraph B
          D[Syscall Interceptor];
          E[ML Inference Engine];
          F[Resource Controller <br/> (cgroups)];
          G[Security Controller <br/> (seccomp)];
          D --> E;
          E --QoS Prediction--> F;
          E --Anomaly Score--> G;
      end
  
      F --adjusts limits--> A;
      F --adjusts limits--> C;
      G --quarantines on alert--> A;
  

---

Axis 5: The "Inverse" or Failure Mode

6. Derivative: Graceful Degradation Container for Low-Power IoT Edge Devices

• Enabling Description: A container running on a battery-powered device (e.g., a remote sensor) is designed for graceful degradation. The host OS notifies the "run time module" of changes in power state (e.g., battery < 20%). The module then activates a "degradation policy." It intercepts system calls and injects faults or modifies parameters. For example, send() calls are throttled to reduce network radio usage, fsync() calls are converted to no-ops to minimize flash writes, and nanosleep() requests are artificially lengthened to reduce CPU wake-ups. This forces the application into a low-fidelity but still-functional state, preserving battery life for critical functions.

• Diagram:

  sequenceDiagram
      participant HostOS
      participant RuntimeModule as Run Time Module
      participant App as Application
      
      HostOS->>RuntimeModule: Event: Battery Level < 20%
      RuntimeModule->>RuntimeModule: Activate "Low Power" Policy
      
      loop Application Logic
          App->>RuntimeModule: syscall: send(data)
          RuntimeModule->>RuntimeModule: Apply Throttling (add delay)
          RuntimeModule->>App: return success (delayed)
          
          App->>RuntimeModule: syscall: nanosleep(10ms)
          RuntimeModule->>RuntimeModule: Lengthen sleep to 50ms
          RuntimeModule->>App: return success (after 50ms)
      end loop
  

---

Claim 2 Derivations: Variations on the Containerization System

Axis 1: Component & Architecture Substitution

7. Derivative: eBPF-Based Runtime Module for In-Kernel Monitoring and Control

• Enabling Description: The "run time module" is not a loadable kernel module but is instead implemented as a suite of eBPF (extended Berkeley Packet Filter) programs attached to kernel tracepoints and kprobes. These eBPF programs run in a sandboxed in-kernel VM, providing a safe and performant way to intercept events. An eBPF program attached to the sys_enter tracepoint can inspect system calls from processes belonging to a container's cgroup. It can read container-specific configuration from eBPF maps (key-value stores) to enforce resource limits or return spoofed data by modifying register values before the actual system call executes. This architecture is upgradable without rebooting the host and is a standard feature in modern Linux kernels.

• Diagram:

  classDiagram
      direction LR
      class UserSpaceController {
        +load_bpf_programs()
        +update_bpf_maps(container_id, config)
      }
      class Kernel {
        <<eBPF VM>>
        +kprobe__sys_uname()
        +tracepoint__sys_enter()
      }
      class BpfMap_ContainerConfig {
        <<key-value>>
        key: cgroup_id
        value: hostname, ip_addr
      }
      class BpfMap_ResourceUsage {
        <<key-value>>
        key: cgroup_id
        value: cpu_cycles, mem_bytes
      }
  
      UserSpaceController -- Manages --> Kernel
      Kernel -- Reads/Writes --> BpfMap_ContainerConfig
      Kernel -- Reads/Writes --> BpfMap_ResourceUsage
      note for Kernel "eBPF programs run here, triggered by syscalls"
  

---

Axis 3: Cross-Domain Application

8. Derivative: Sandboxed Container System for In-Vehicle Infotainment (IVI)

• Enabling Description: An automotive-grade Linux system running on a vehicle's head unit uses containerization to isolate third-party applications (e.g., media players, navigation apps). Each application is delivered as a container image. The "run time module" is integrated with the vehicle's CAN (Controller Area Network) bus gateway. It uses system call interception to enforce a strict security policy: only the container designated as the "Navigation App" is allowed to make system calls that access the GPS device file (/dev/gnss0), and no third-party container is allowed to make ioctl() calls to the CAN bus driver, preventing a compromised music app from sending malicious commands to vehicle control systems like braking or steering. Each container is given a unique identity on the vehicle's internal Ethernet network.

• Diagram:

  flowchart LR
      subgraph IVI Head Unit
          A[Music App Container] --syscall--> B{Run Time Module}
          C[Nav App Container] --syscall--> B
          D[HVAC UI Container] --syscall--> B
      end
      
      subgraph Vehicle Hardware
          E[CAN Bus]
          F[GPS Device]
          G[Audio DAC]
      end
  
      B -- Denies Access --> E
      B -- Grants Access to C only --> F
      B -- Grants Access --> G
      
      style A fill:#f9f,stroke:#333,stroke-width:2px
      style C fill:#ccf,stroke:#333,stroke-width:2px
      style D fill:#cfc,stroke:#333,stroke-width:2px
  

---

Axis 4: Integration with Emerging Tech

9. Derivative: Container Identity Management via SPIFFE/SPIRE for Zero-Trust Networking

• Enabling Description: The "unique identity" of a container (IP address, hostname) is augmented with a strong cryptographic identity based on the open SPIFFE standard. A SPIRE agent daemon runs on the host server. The "run time module" intercepts a container's startup process. After the container's primary process is launched, the module queries the SPIRE agent to attest the container's identity (based on its file hashes, parent process, etc.). Upon successful attestation, the SPIRE agent provisions a unique, short-lived X.509 certificate (an SVID) into the container's memory via a shared volume. The application within the container can then use this certificate to establish mutually authenticated TLS (mTLS) connections with other services, creating a zero-trust network where identity is cryptographically proven rather than inferred from an IP address.

• Diagram:

  sequenceDiagram
      participant App as Application Process
      participant RuntimeModule as Run Time Module
      participant SpireAgent as SPIRE Agent (Host)
      participant SpireServer as SPIRE Server (Cluster)
  
      RuntimeModule->>App: Start application process
      RuntimeModule->>SpireAgent: Request attestation for new process
      SpireAgent->>SpireServer: Attest workload identity
      SpireServer-->>SpireAgent: Attestation successful, issue SVID
      SpireAgent->>RuntimeModule: Provide SVID (X.509 Certificate)
      RuntimeModule->>App: Mount SVID into container's filesystem
      App->>App: Load SVID for mTLS connections
  

---

Combination Prior Art Scenarios

10. Combination: OCI-compliant Containers with seccomp-bpf Runtime Module

• Enabling Description: This system combines the containerization concept with the open standards established by the Open Container Initiative (OCI). The "container" is an OCI-compliant filesystem bundle. The "run time module" is implemented entirely through standard Linux kernel features configured by an OCI-compliant runtime like runc. The container's unique identity (hostname, IP) is configured via Linux namespaces. Security isolation and system call interception are achieved by generating a seccomp-bpf filter from a profile defined in the container's config.json. This filter denies unauthorized system calls and can use SECCOMP_RET_TRACE to pass specific calls to a user-space process for "spoofing" values, fulfilling the patent's functional claims using only open, standardized components.

11. Combination: Kubernetes-Managed Containers with Istio Service Mesh Identity

• Enabling Description: The system described in the patent is implemented at a higher level of abstraction using Kubernetes and the Istio service mesh. Kubernetes acts as the container orchestrator, managing the lifecycle of standard Docker/OCI containers. The "unique identity" is provided at two levels: Kubernetes assigns a unique IP and DNS name to each container (Pod). Istio injects a sidecar proxy into each Pod, which intercepts all network traffic. This sidecar enforces network policies and provides a strong, SPIFFE-based cryptographic identity for zero-trust communication, acting as a network-level "run time module" that is external to the application's process and the host kernel.

12. Combination: WebAssembly Modules with WASI and a Centralized Policy Engine

• Enabling Description: This system uses WebAssembly (Wasm) as the "container" format and the WebAssembly System Interface (WASI) as the mechanism for the "run time module." The application is compiled to a Wasm binary. It is executed by a Wasm runtime (e.g., Wasmtime). All I/O, file access, and network calls from the Wasm module are mediated through the WASI API implemented by the runtime. The runtime is configured by a central policy engine (e.g., Open Policy Agent) which defines the container's permissions, resource limits, and what "spoofed" environment variables or hostnames it sees. This achieves kernel-less isolation and control in a portable, platform-agnostic manner.