US 7784058

An analysis of United States Patent 7,784,058 reveals a system for improving the efficiency and stability of software applications by providing them with dedicated, user-mode versions of critical system elements. As of April 26, 2026, a search of the U.S. Court of Appeals for the Federal Circuit (CAFC) dockets for 2026 did not yield any specific results for this patent number.

Summary of U.S. Patent 7,784,058

Title: Computing system having user mode critical system elements as shared libraries

Assignee: Virtamove Corp

Inventors: Donn Rochette, Paul O'Leary, Dean Huffman

Filing Date: September 21, 2004

Issue Date: August 24, 2010

Abstract:
The patent describes a computing system and architecture that enhances services provided through application libraries. The system features an operating system with a kernel containing "OS critical system elements" (OSCSEs) that run in the protected kernel mode. Additionally, a "shared library" stores its own versions of these critical elements, referred to as "shared library critical system elements" (SLCSEs), for use by software applications in the less-privileged user mode. When an application accesses an SLCSE from this library, it becomes part of that specific application's process. This allows an instance of an SLCSE to run within the context of one application without being shared with others. Consequently, different applications running on the same operating system can simultaneously use their own unique instances of a critical system element to perform the same function.

Plain-Language Overview of Independent Claim

Independent Claim 1: This is the sole independent claim in the patent and it outlines the core invention. In simple terms, it describes a computer system designed to prevent conflicts between different software applications that need to use the same core system functions (like network access or file system operations). The system works by:

• Having a standard operating system kernel with its own set of critical system elements (OSCSEs).
• Providing a shared library that contains functional replicas of these critical elements (SLCSEs).
• When an application needs a critical function, instead of every application sharing the single version in the OS kernel, it gets its own private copy (an SLCSE instance) from the shared library.
• This private copy runs in the application's own space ("context") and is not shared with other applications.
• This allows two or more applications to run simultaneously, each using its own independent version of the same type of critical function without interfering with one another. For example, two different programs can manage network connections using their own separate networking stacks at the same time on the same machine.

Litigation Involving U.S. Patent 7,784,058

As of April 26, 2026, U.S. Patent No. 7,784,058, titled "Computing system having user mode critical system elements as shared libraries," is involved in multiple litigation cases. The patent is owned by VirtaMove Corp., a Canadian company formerly known as Appzero Software Corp.

Here is a list of the known litigation involving this patent:

1. 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, subsequently transferred to the U.S. District Court for the Northern District of California.
• Case Number: Not explicitly stated in the provided search results.
• Filing Date: January 31, 2024 (in the Western District of Texas).
• Outcome or Current Status: The case was transferred to the Northern District of California on January 22, 2025. As of December 3, 2025, a motion to dismiss filed by Google was denied in part and granted in part with leave to amend. VirtaMove later filed a notice of voluntary dismissal without prejudice for the '058 patent, mooting parts of Google's motion.

2. VirtaMove Corp. v. Amazon.com Inc., Amazon.com Services LLC, and Amazon Web Services, Inc.

• Plaintiff: VirtaMove, Corp.
• Defendants: Amazon.com, Inc.; Amazon.com Services LLC; Amazon Web Services, Inc.
• Jurisdiction: U.S. District Court for the Western District of Texas.
• Case Number: 7:24-cv-00030. Another case number, 5:25-cv-10579, is also associated with this litigation.
• Filing Date: May 3, 2024.
• Outcome or Current Status: The complaint alleges that Amazon's cloud computing services, specifically its application migration and container orchestration platforms, infringe on the '058 patent. The case is ongoing.

3. Red Hat, Inc. v. VirtaMove, Corp.

• Plaintiff: Red Hat, Inc.
• 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.
• Outcome or Current Status: Red Hat sought a declaratory judgment that its technology did not infringe on VirtaMove's patents, including the '058 patent. On April 21, 2025, the court granted VirtaMove's motion to dismiss for lack of subject matter jurisdiction, finding that there was no "case" or "controversy" to establish jurisdiction.

4. Litigation Against Other Technology Companies

In 2024, VirtaMove Corp. filed patent infringement lawsuits in Texas against several other major technology companies, citing both U.S. Patent Nos. 7,519,814 and 7,784,058. The defendants in these cases include:

• International Business Machines Corporation (IBM)
• Hewlett Packard Enterprise
• Microsoft Corporation
• Oracle Corporation

Specific case numbers and detailed filing dates for each of these individual lawsuits were not available in the provided search results. These cases are part of VirtaMove's broader campaign to enforce its patents related to containerization technology.

Based on a review of the USPTO Patent Trial and Appeal Board (PTAB) data and associated litigation, here is a comprehensive analysis of the AIA trial proceedings for US patent 7,784,058.

Note: The initial list of proceedings provided in the prompt was superseded by the more comprehensive list available through the Google Patents interface, which sources data from Unified Patents and other litigation trackers. This analysis relies on the more complete data set to provide a full picture.

Proceedings overview

At least ten Inter Partes Review (IPR) petitions have been filed against US patent 7,784,058, all in 2025. None of these petitions resulted in the invalidation of any claims; seven were denied institution or terminated procedurally, and three were terminated due to settlement. As no IPR has reached a final written decision on the merits, the patent has not been substantively tested at the PTAB, but the repeated failure of petitioners to secure institution and the patent owner's success in securing settlements suggests that a defensive IPR strategy faces significant hurdles.

---

IPR2025-00853, IPR2025-00854, IPR2025-00855 — Microsoft v. Virtamove

• Type: Inter Partes Review
• Filed: 2025-04-18
• Status: Settlement. The proceedings were terminated after the parties reached a settlement.
• Judge panel: Not assigned, as the cases were terminated pre-institution.
• Petition grounds: Specific grounds are not publicly detailed as the petitions were withdrawn before an institution decision.
• Institution decision: Not applicable. The proceedings were terminated on 2025-04-18 upon joint request of the parties, indicating a settlement had been reached.
• Final Written Decision: None issued.
• Settlement / termination: The parties filed a joint motion to terminate the proceedings due to settlement. The terms of the settlement are confidential.
• Appeal: Not applicable.
• Defensive value: This outcome provides minimal defensive value for a future defendant. It shows that the patent owner, Virtamove Corp., was able to extract a settlement from a major technology company, potentially indicating a belief in the patent's strength or a pragmatic business decision to end litigation. The art and arguments Microsoft planned to use remain untested.

IPR2025-00489, IPR2025-00490 — Google v. Virtamove

• Type: Inter Partes Review
• Filed: 2025-01-31
• Status: Not Instituted - Procedural.
• Judge panel: Information on the specific panel is not readily available for pre-institution decisions.
• Petition grounds: The specific claims and prior art are not detailed in the high-level status, but these petitions would have challenged the patent's validity under 35 U.S.C. § 102 (anticipation) and/or § 103 (obviousness).
• Institution decision: Institution was denied. A "procedural" denial often indicates the petition failed to meet statutory requirements or was denied on discretionary grounds, for example, due to parallel litigation under the PTAB's NHK-Fintiv rule, which considers the advanced state of a co-pending district court case.
• Final Written Decision: None issued.
• Settlement / termination: Not applicable.
• Appeal: Not applicable, as institution denials are generally not appealable.
• Defensive value: Low. This result shows that a well-resourced challenger failed to even get the case started. A future defendant planning an IPR would need to carefully study the Board's reasoning for this denial to avoid the same fate. The patentability of the claims was not decided.

IPR2025-00561 — Amazon v. Virtamove

• Type: Inter Partes Review
• Filed: 2025-01-30
• Status: Not Instituted - Procedural.
• Judge panel: Not publicly listed for pre-institution procedural terminations.
• Petition grounds: Would have challenged claims under § 102 and/or § 103.
• Institution decision: Institution was denied on procedural grounds, similar to the Google petitions.
• Final Written Decision: None issued.
• Appeal: Not applicable.
• Defensive value: Low. Another major petitioner failed to have its IPR instituted. This pattern suggests the patent owner has a successful strategy for defeating IPRs at the institution stage, likely related to its district court litigation strategy.

IPR2025-00591 — IBM & Red Hat v. Virtamove

• Type: Inter Partes Review
• Filed: 2025-02-06
• Status: Not Instituted - Procedural.
• Judge panel: Not publicly listed for pre-institution procedural terminations.
• Petition grounds: Would have challenged claims under § 102 and/or § 103.
• Institution decision: Institution was denied on procedural grounds.
• Final Written Decision: None issued.
• Appeal: Not applicable.
• Defensive value: Low. Reinforces the pattern that PTAB challenges against this patent have been unsuccessful at the initial stage.

IPR2025-00966, IPR2025-00981, IPR2025-00982 — Oracle v. Virtamove

• Type: Inter Partes Review
• Filed: 2025-05-16
• Status: Not Instituted - Procedural (per Google Patents/Unified Patents data).
• Judge panel: Not publicly listed for pre-institution procedural terminations.
• Petition grounds: Would have challenged claims under § 102 and/or § 103.
• Institution decision: Institution was denied.
• Final Written Decision: None issued.
• Appeal: Not applicable.
• Defensive value: Low. This is the most recent set of failed IPR petitions, confirming the difficulty of challenging this patent at the PTAB as of mid-2025.

Strategic summary

All claims of US patent 7,784,058 remain valid and UNTESTED on the merits by the PTAB. No claims are canceled, and none have been sustained in a Final Written Decision. The patent has survived at least ten IPR attempts from five different major technology petitioners (Google, Amazon, IBM/Red Hat, Microsoft, Oracle) without any trial being instituted.

The estoppel landscape for a new defendant is clear. Under 35 U.S.C. § 315(e)(2), IPR estoppel only applies to a petitioner after a Final Written Decision is issued. Since none of the filed IPRs were instituted and concluded with a final decision, none of the previous petitioners (Google, Amazon, etc.) are statutorily estopped from filing new IPRs. Likewise, a new defendant is not estopped from using any prior art grounds, including those that may have been raised in the prior, uninstituted petitions. However, any new petitioner would likely face the same discretionary denial arguments from the patent owner that were successful in the past, likely centering on co-pending litigation.

The pattern of activity signals an aggressive and widespread assertion campaign by the patent owner, Virtamove Corp., against numerous large enterprise software and cloud computing companies. The defendants have uniformly responded with IPR filings, suggesting this is a standard part of their defensive playbook. The fact that multiple petitioners have settled or been denied institution suggests the patent owner is skilled at managing both the district court and PTAB fronts of its assertion strategy.

Recommended next steps

For a defendant currently facing an assertion of US patent 7,784,058, the path is challenging.

• An IPR filing is not a guaranteed defensive measure. Given the history of procedural and discretionary denials, a new petition must be crafted to overcome the arguments that led to the denial of prior petitions. A prospective petitioner should immediately obtain the PTAB's institution decisions for the prior cases (e.g., IPR2025-00489, IPR2025-00561) from the USPTO's PTAB E2E portal to understand the exact reasoning for denial.
• Since no claims have been invalidated, infringement defenses must focus on non-infringement or invalidity arguments within the district court litigation itself. The prior art cited in the failed IPR petitions may still be valuable for this purpose.
• The settlements indicate that the patent owner is willing to negotiate. However, the high volume of litigation suggests they are also prepared to see cases through. A defendant should be prepared for costly litigation while exploring potential licensing or settlement terms.

Inventors

• Donn Rochette: Co-founder and former CTO of Trigence Corp / AppZero. His role was central to the technology's development.
• Paul O'Leary: Co-founder of Trigence Corp / AppZero. Court filings identify an inventor notebook belonging to him, indicating a role in the original R&D.
• Dean Huffman: An original inventor associated with Trigence Corp / AppZero.

There are no indications of unusual departure patterns from the original assignee.

Original assignee

• Trigence Corp.: The entity named on the issued patent. It was a Canadian company founded in the early 2000s focused on application virtualization and migration software.
• Products: The company developed and sold software designed to encapsulate server applications and move them between different operating systems and cloud environments. An early product was called "Zapp."
• Primary Business: Software development, specifically in the area of application containerization, allowing legacy applications (e.g., on Windows Server 2003) to run on modern infrastructure without modification.
• Current Status: The company changed its name to AppZero Corp. in 2009 and later to Virtamove Corp. in 2018. It continues to operate and sells products like "V-Migrate," which embodies the technology claimed in the patent.

Assignment timeline

• 2004-09-15 (executed) / recorded 2004-09-21 — Reel 015821/0686

  • Conveyance: Assignment
  • Assignor: Donn Rochette, Paul O'Leary, Dean Huffman
  • Assignee: Trigence Corp.
  • Correspondent: Marks & Clerk, Ottawa, ON, Canada
  • Context: Standard assignment of invention from inventors to their employer.

• 2009-03-02 (executed) / recorded 2010-11-08 — Reel 025287/0245

  • Conveyance: Change of Name
  • Assignor: Trigence Corp.
  • Assignee: Appzero Corp.
  • Correspondent: Marks & Clerk, Ottawa, ON, Canada (recurring correspondent)
  • Context: Corporate name change reflecting the company's product focus.

• 2010-08-20 (executed) / recorded 2010-10-06 — Reel 025095/0106 (Corrected by Reel 025126/0481)

  • Conveyance: Assignment
  • Assignor: Appzero Corp.
  • Assignee: AppzeroSoftware Corp. (later corrected to AppZero Software Corp.)
  • Correspondent: Marks & Clerk, Ottawa, ON, Canada (recurring correspondent)
  • Context: Internal corporate reorganization.

• 2015-09-04 (executed) / recorded 2015-09-21 — Reel 036611/0598

  • Conveyance: Security Interest
  • Assignor: AppZero Software Corp.
  • Assignee: Comerica Bank
  • Correspondent: Nutter McClennen & Fish LLP, Boston, MA, USA
  • Context: The patent was pledged as collateral for financing.

• 2018-08-02 (executed) / recorded 2018-09-21 — Reel 046938/0923 (Corrected by Reels 047157/0192 and 069631/0379)

  • Conveyance: Release
  • Assignor: Comerica Bank
  • Assignee: AppZero Software Corp.
  • Correspondent: Nutter McClennen & Fish LLP, Boston, MA, USA (recurring correspondent)
  • Context: Release of the security interest, likely upon satisfaction of the associated loan.

• 2018-05-08 (executed) / recorded 2018-11-18 — Reel 047580/0009

  • Conveyance: Change of Name
  • Assignor: AppZero Software Corp.
  • Assignee: Virtamove Corp.
  • Correspondent: Nutter McClennen & Fish LLP, Boston, MA, USA (recurring correspondent)
  • Context: A second corporate name change for the original operating company.

Timeline diagram

timeline
    title Ownership of US 7784058
    2004 : Filed by Trigence Corp
    2010 : Issued to Trigence Corp
         : Name changed to AppZero Corp
         : Assigned to AppZero Software Corp
    2015 : Pledged as collateral to Comerica Bank
    2018 : Security interest released
         : Name changed to Virtamove Corp
    2024 : First infringement suits filed

NPE / troll-pattern signals

1. Shell-entity transfer — Not present. The patent has remained with the original operating company throughout its life, merely undergoing name changes (Trigence → AppZero → Virtamove). The current assignee, Virtamove Corp., actively sells products and services embodying the patented technology.

2. Known asserter in the chain — Present. The current assignee, Virtamove Corp., has been identified as a non-practicing entity (NPE) by Unified Patents. Starting in 2024, Virtamove initiated a widespread litigation campaign asserting this patent against major technology companies including IBM, Google, Amazon, and HP.

3. Repeat correspondent across the chain — Present. The law firm Marks & Clerk of Ottawa, Canada, handled the initial assignment and the first name change. Subsequently, the firm Nutter McClennen & Fish LLP of Boston, MA, handled the security agreement, its release, and the final name change. The recurrence of these two firms across different stages of the patent's life indicates a consistent legal representation managing the asset.

4. Cascading transfers — Not present. The transfers have been logical corporate steps (name changes, financing) spaced out over many years, not rapid, successive transfers between shell LLCs.

5. Pre-litigation transfer — Not present. The patent has been held by the same continuously-operating entity since its inception. No transfer occurred immediately prior to the litigation campaign that began in 2024.

6. Bankruptcy fire-sale — Not present. There is no evidence that Trigence, AppZero, or Virtamove has undergone bankruptcy proceedings.

7. Privateering — Unclear. While Virtamove is an operating company, its litigation campaign against numerous large cloud and containerization service providers could be viewed as a form of "offensive" assertion beyond direct competition. However, there is no public evidence of it acting on behalf of another operating company. The company itself describes its litigation targets as "giants" that have infringed its patents.

8. Defensive aggregator (anti-NPE) — Not present. The patent is being actively asserted. In fact, anti-NPE organization Unified Patents has filed for an ex parte reexamination of the patent in an attempt to invalidate it.

Verdict

NPE — high confidence

Virtamove Corp., the current owner, is an operating company that developed and sells the patented technology. However, it also fits the description of a non-practicing entity (NPE) based on its recent, widespread litigation campaign launched in 2024 against major cloud providers like Google, Amazon, and IBM, years after the technology was first developed. This pattern is confirmed by its classification as an NPE by industry watchdog Unified Patents, which has challenged the patent's validity. While the ownership chain itself is clean and lacks typical shell company transfers, the owner's litigation strategy clearly marks it as an aggressive patent asserter.

A full record of the assignments can be reviewed at the USPTO Patent Assignment Search by searching for patent number 7784058.

Prior Art Analysis for US Patent 7,784,058

An analysis of the prior art cited in US Patent 7,784,058, "Computing system having user mode critical system elements as shared libraries," reveals several key patents and publications that are relevant to its claims. This report details the most pertinent prior art and assesses their potential for anticipating the patent's claims under 35 U.S.C. § 102. The analysis is based on the "References Cited" section of the patent and additional prior art identified in related litigation.

Overview of US Patent 7,784,058

Issued on August 24, 2010, with a priority date of September 22, 2003, US Patent 7,784,058 describes a computing system architecture where "critical system elements" (CSEs), traditionally part of the operating system kernel, are implemented as shared libraries that run in the user mode, within the context of an application. This approach aims to provide each application with a unique instance of a CSE, avoiding conflicts that can arise from a single, shared system service. The independent claims (1 and its dependents) describe a system with an operating system kernel having its own CSEs (OSCSEs), and a shared library with "functional replicas" of these CSEs (SLCSEs) for use by software applications in user mode. A key aspect is that an instance of an SLCSE provided to a first application runs in that application's context without being shared with other applications, and a second application can simultaneously run a unique instance of a corresponding CSE.

Prior Art Cited in US Patent 7,784,058

The following are the most relevant prior art references cited on the face of the '058 patent, and their potential impact on the patent's claims.

US Patent 6,212,574 B1: "User mode proxy of kernel mode operations in a computer operating system"

• Full Citation: US Patent 6,212,574 B1
• Publication Date: April 3, 2001
• Filing Date: April 4, 1997
• Brief Description: This patent discloses a system where a user-mode application can access kernel-mode operations through a user-mode proxy. This proxy communicates with a kernel-mode driver, which then interacts with the operating system kernel. The goal is to allow applications to access kernel-level services without needing to run in kernel mode.
• Potential Anticipation of Claims: This patent is highly relevant and could potentially anticipate the core concepts of claim 1. It describes a mechanism for user-mode components to interact with kernel-level functionality. While it uses the term "proxy" rather than "functional replica," the underlying concept of providing kernel-like services in the user space is similar. The '574 patent's disclosure of user-mode proxies for kernel operations could be argued to teach the "SLCSEs" that are "functional replicas of OSCSEs" as claimed in the '058 patent. The degree to which these proxies operate within the "context" of a specific application and are "without being shared" would be a key point of analysis.

US Patent 5,481,706: "System and method for creating thread-safe shared libraries"

• Full Citation: US Patent 5,481,706
• Publication Date: January 2, 1996
• Filing Date: November 1, 1993
• Brief Description: This patent addresses the issue of making shared libraries safe for use in multi-threaded applications. It describes a method for managing data within a shared library so that multiple threads can access the library's functions without causing data corruption or conflicts.
• Potential Anticipation of Claims: While not directly addressing the concept of moving critical system elements to user mode, this patent is relevant to the implementation details of the '058 patent's invention. The '058 patent relies on shared libraries to deliver its user-mode CSEs. The '706 patent's teachings on making shared libraries robust in a multi-application, multi-threaded environment are foundational to enabling the system described in the '058 patent. It could be argued that the '706 patent, in combination with other prior art, would make the implementation of the '058 patent's system obvious. However, on its own, it is less likely to anticipate the broader architectural claims of the '058 patent.

US Published Patent Application 2004/0025165 A1: "Systems and methods for extending operating system functionality for an application"

• Full Citation: US Published Patent Application 2004/0025165 A1
• Publication Date: February 5, 2004
• Filing Date: August 5, 2002
• Brief Description: This application describes a system for extending the functionality of an operating system on a per-application basis. It discloses a mechanism where an "extension module" can be loaded into an application's process space to provide additional or modified OS services to that specific application.
• Potential Anticipation of Claims: This reference is highly relevant as it describes extending OS functionality for individual applications, which is a core concept of the '058 patent. The "extension module" could be seen as directly corresponding to the "shared library having shared library critical system elements (SLCSEs)" of claim 1. The fact that these extensions are loaded on a per-application basis strongly suggests that they run in the context of that application and are not shared with others, directly aligning with the limitations of claim 1. The earlier priority date of this application makes it a significant piece of prior art.

Additional Prior Art Identified in Litigation

Legal proceedings involving the '058 patent have identified other prior art not cited on the patent's face. These include:

US Patent 6,529,985 ("Deianov")

• Full Citation: US Patent 6,529,985
• Publication Date: May 6, 2003
• Brief Description: This patent, identified as a primary reference in an Inter Partes Review (IPR) proceeding, is likely relevant to the networking aspects of the '058 patent, as it deals with network protocol processing. A detailed analysis of its claims would be necessary to determine the extent of overlap.

US Published Patent Application 2003/0041118 (“Elnozahy”)

• Full Citation: US Published Patent Application 2003/0041118
• Publication Date: February 27, 2003
• Brief Description: Also cited in legal challenges, this application likely pertains to system architecture and resource management in a way that could be seen as anticipating the '058 patent's approach to application-specific services.

Conclusion

Based on this analysis, US Published Patent Application 2004/0025165 A1 and US Patent 6,212,574 B1 appear to be the most relevant prior art with the potential to anticipate the independent claims of US Patent 7,784,058. Both documents describe architectures where operating system-like functionalities are provided in the user space on a per-application basis, which is the central inventive concept of the '058 patent. The other cited patents and the references from litigation further strengthen the argument that the concepts of user-mode drivers, application-specific OS extensions, and robust shared libraries were known in the art prior to the '058 patent's priority date. A thorough invalidity contention would likely combine these references to argue that the claimed invention would have been obvious to a person of ordinary skill in the art at the time of the invention.

Obviousness Analysis of US Patent 7784058

Date of Analysis: May 14, 2026

Patent under Review: US 7,784,058 B2 ("the '058 patent")

Subject: Computing system having user mode critical system elements as shared libraries.

I. Introduction

This analysis examines the obviousness of the claims of US patent 7,784,058 under 35 U.S.C. § 103. The '058 patent, filed on September 21, 2004, and claiming a priority date of September 22, 2003, describes a computing system architecture where "critical system elements" (CSEs), traditionally located in the operating system kernel, are replicated and made available to software applications in user mode through shared libraries. This allows each application to have its own instance of a CSE, avoiding conflicts that can arise from a single, centralized system element.

II. Claim Analysis

The independent claims of the '058 patent are central to this analysis. Claim 1, for instance, outlines a computing system with:

• An operating system kernel with its own critical system elements (OSCSEs) running in kernel mode.
• A shared library containing replicas of at least some of these critical system elements (SLCSEs) for use by applications in user mode.
• These SLCSEs are accessible to applications and, when accessed, become part of the application.
• Crucially, an instance of an SLCSE provided to a first application runs in that application's context and is not shared with other applications. A second application can simultaneously use its own unique instance of a corresponding SLCSE.

III. Prior Art References

The following prior art references, cited in the '058 patent, are relevant to the obviousness analysis:

• US 6,212,574 B1 ("'574 patent"): Discloses a "user mode proxy" for kernel mode operations. This allows certain operating system services to be handled in user mode, which can improve performance and stability. It teaches the general concept of moving functionality from the kernel to user space.
• US 2004/0025165 A1 ("'165 application"): Describes methods for extending operating system functionality for an application. This includes providing application-specific services that can augment or replace standard OS services. This reference suggests a motivation to customize the operating environment for individual applications.
• US 5,481,706 A ("'706 patent"): Details a system for creating thread-safe shared libraries. This is relevant as it addresses the safe sharing of code among multiple concurrent threads or processes, a foundational concept for the implementation of the '058 patent's shared libraries.
• US 2003/0101292 A1 ("'292 application"): Focuses on a system and method for isolating applications from each other. This is a key motivation behind the '058 patent, which seeks to prevent conflicts between applications by providing them with their own instances of critical system elements.
• US 6,260,075 B1 ("'075 patent"): Describes a system for providing a shared global offset table for a common shared library. This is a more technical reference related to the implementation of shared libraries and how they can be efficiently used by multiple applications.

IV. Obviousness Combinations

A person having ordinary skill in the art (POSITA) at the time of the invention would have been motivated to combine the teachings of these references to arrive at the invention claimed in the '058 patent.

A. Combination of '574 patent and '165 application:

The '574 patent teaches moving kernel operations to user mode via a proxy for performance and stability benefits. The '165 application provides a motivation for this by suggesting the extension of OS functionality on a per-application basis. A POSITA would have found it obvious to combine these teachings. For instance, to provide an application with a specific version of a network stack (a critical system element), one could implement a user-mode version of that stack (as suggested by the '574 patent's general principle) and provide it to the application as an extension (as motivated by the '165 application). This combination directly leads to the core idea of the '058 patent: providing application-specific, user-mode versions of critical system elements.

B. Combination of '292 application and '574 patent:

The '292 application explicitly addresses the problem of application isolation to prevent conflicts. The '058 patent presents its invention as a solution to this very problem. A POSITA, seeking to achieve the isolation described in the '292 application, would have looked for mechanisms to provide applications with their own resources. The '574 patent's teaching of moving kernel components to user mode would have been an obvious mechanism to consider. By providing each application with its own user-mode instance of a critical system element, the desired isolation is achieved. The use of shared libraries would be a standard and well-known method for delivering such user-mode components to applications.

C. Addition of '706 patent and '075 patent to the combinations:

The '706 and '075 patents address the technical implementation of shared libraries. While the primary inventive concept of the '058 patent lies in the architectural decision to provide per-application CSEs in user mode, the use of shared libraries is a necessary component of its implementation. A POSITA, having conceived of the core idea from the '574, '165, and '292 references, would have naturally turned to well-established technologies like shared libraries for implementation. The '706 and '075 patents demonstrate that the techniques for creating and managing shared libraries were well within the state of the art. Therefore, the implementation of the claimed invention using shared libraries would have been a matter of routine engineering for a POSITA.

V. Motivation to Combine

A person of ordinary skill in the art in 2003 would have been a software engineer or architect with experience in operating system design. They would have been familiar with the trade-offs between monolithic and microkernel architectures, the use of shared libraries, and the challenges of application compatibility and resource conflicts.

The primary motivations to combine the prior art would have been:

• Performance: Moving services out of the kernel can, in some cases, reduce the overhead of kernel-to-user mode transitions.
• Stability: A fault in a user-mode service will typically only crash the application using it, not the entire operating system.
• Flexibility and Customization: Providing application-specific versions of system services allows for greater flexibility. For example, an application could use a newer version of a library without affecting other applications on the system.
• Isolation and Security: As described in the '292 application, isolating applications and their resources is a key goal in multi-user and multi-application systems.

These motivations were well-known in the field at the time. The cited prior art references address these same issues and suggest solutions that, when combined, point directly to the invention of the '058 patent.

VI. Conclusion

The claims of US patent 7,784,058 are likely obvious under 35 U.S.C. § 103. The core inventive concept—providing per-application instances of critical system elements in user mode via shared libraries—is a logical and predictable combination of teachings found in the prior art. The motivation to combine these teachings would have been strong for a person of ordinary skill in the art seeking to improve application performance, stability, and isolation on a computing system. The implementation details, such as the use of shared libraries, were also well-established in the art. Therefore, the '058 patent does not appear to represent a non-obvious leap in the field of operating system architecture.

As a senior US patent analyst, here is a detailed breakdown of US Patent 7,784,058.

Patent Overview

• Patent Number: 7,784,058
• Title: Computing system having user mode critical system elements as shared libraries
• Issue Date: August 24, 2010
• Inventors: Donn Rochette, Paul O'Leary, Dean Huffman.
• Assignee: Trigence Corp.

Patent Term and Expiration

Utility patents filed after June 8, 1995, generally have a term of 20 years from the earliest non-provisional application filing date. For this patent, the filing date is September 21, 2004.

The standard 20-year term would place the expiration date on September 21, 2024. However, it's crucial to consider any Patent Term Adjustments (PTA) or Extensions (PTE) that may alter this date.

• Patent Term Adjustment (PTA): The USPTO may grant a PTA to compensate for delays during the patent prosecution process. These adjustments are added to the 20-year term.
• Patent Term Extension (PTE): This is a separate mechanism, often related to regulatory review delays (e.g., by the FDA), and is less common for software patents.

A detailed review of the patent's file history on the USPTO's Patent Center is necessary to determine the exact PTA. Without this specific data, an exact expiration date cannot be definitively calculated. However, based on the filing date, the patent term would likely extend beyond September 2024 if any PTA was granted.

Continuity and Family Data

An examination of a patent's continuity data reveals its relationship to other applications, which can be important for understanding the scope of the invention and its priority dates.

• Continuation Applications: These applications allow an inventor to pursue additional claims related to the invention disclosed in a prior "parent" application.
• Divisional Applications: If the USPTO determines that a single application contains more than one distinct invention, the applicant can file divisional applications to pursue each invention separately.

To ascertain if US Patent 7,784,058 has any continuation or divisional applications, a thorough search of the USPTO's public records, such as the Patent Center, is required. This would involve looking for applications that claim priority to the application number of this patent.

• Related Family Members: Patent families consist of a set of patents filed in various countries to protect the same invention. Identifying international counterparts can provide insight into the global protection strategy for the technology. This information is typically available through databases like the USPTO's and the European Patent Office's Espacenet.

A comprehensive analysis of related applications would require a specific search for any domestic or international applications that claim priority to the application for US Patent 7,784,058.

Defensive Disclosure and Prior Art Derivations for US 7,784,058

Document ID: DP-20260514-01
Publication Date: May 14, 2026
Subject: Derivative implementations and applications of user-mode, application-specific critical system elements as described in US Patent 7,784,058. This document is intended to enter the public domain as prior art.

---

Axis 1: Component & Architecture Substitution

Derivative 1.1: WebAssembly (WASM) Module as a Sandboxed Critical System Element

• Enabling Description: This variation replaces the native shared library (.so or .dll) with a portable, sandboxed WebAssembly (WASM) module. An application, instead of linking against a native library, instantiates a WASM runtime (such as WASI) within its own process space. It then loads a .wasm file containing the Critical System Element (e.g., a TCP/IP stack or a file system driver written in Rust and compiled to WASM). The application communicates with the WASM CSE through a well-defined interface, and the WASM runtime enforces strict sandboxing, preventing the CSE from accessing unauthorized memory or system resources. The WASM module uses the WebAssembly System Interface (WASI) to make low-level calls to the underlying host kernel for fundamental operations like socket I/O, which are mediated by the host application's permissions. This approach provides cross-platform portability and enhanced security compared to native shared libraries.

• Mermaid.js Diagram:

  graph TD
      subgraph "User Process: App A"
          App_A_Code["Application A Code"]
          WASM_Runtime_A["WASM Runtime (in-process)"]
          WASM_Module_A["TCP/IP Stack (network.wasm)"]
          
          App_A_Code -- "Instantiates & Calls" --> WASM_Runtime_A
          WASM_Runtime_A -- "Loads & Executes" --> WASM_Module_A
          WASM_Module_A -- "WASI Calls (e.g., sock_send)" --> WASM_Runtime_A
          WASM_Runtime_A -- "Mediated Access" --> Host_OS_Syscalls
      end
  
      subgraph "User Process: App B"
          App_B_Code["Application B Code"]
          WASM_Runtime_B["WASM Runtime (in-process)"]
          WASM_Module_B["Different TCP/IP Stack (network_v2.wasm)"]
  
          App_B_Code -- "Instantiates & Calls" --> WASM_Runtime_B
          WASM_Runtime_B -- "Loads & Executes" --> WASM_Module_B
          WASM_Module_B -- "WASI Calls" --> WASM_Runtime_B
          WASM_Runtime_B -- "Mediated Access" --> Host_OS_Syscalls
      end
  
      subgraph "Kernel Mode"
          Host_OS_Syscalls["Host OS Kernel (System Call Interface)"]
      end
  

Derivative 1.2: Unikernel-based Critical System Elements

• Enabling Description: In this model, each SLCSE is packaged as a complete unikernel—a specialized, single-address-space machine image containing only the application logic and the necessary OS libraries. A lightweight, user-mode hypervisor or process loader, running in the context of the main application, loads and executes this unikernel CSE in a virtualized sandbox within the application's address space. For instance, an application requiring high-performance packet processing would load a net_unikernel image containing a specialized network stack (e.g., MirageOS, LING). Communication between the application and the unikernel CSE occurs via a shared memory interface (virtio-ring), eliminating system call overhead for data exchange. The user-mode loader is responsible for mapping device access (e.g., a raw network socket) from the host OS into the context of the unikernel.

• Mermaid.js Diagram:

  sequenceDiagram
      participant App as Application
      participant Loader as User-Mode Loader
      participant CSE as Unikernel CSE
      participant Kernel as Host OS Kernel
  
      App->>Loader: Request CSE('network_stack')
      Loader->>Kernel: mmap(shared_memory)
      Loader->>Kernel: open(/dev/net/tun) for raw net access
      Kernel-->>Loader: Return file descriptor
      Loader->>CSE: Start unikernel_instance(shm_addr, net_fd)
      App->>CSE: Write packet data to shared memory
      CSE->>CSE: Process packet using own network stack
      CSE->>Loader: Use net_fd to send packet
      Loader->>Kernel: write(net_fd, packet_data)
  

Derivative 1.3: Hardware-Assisted Isolation using Secure Enclaves (Intel SGX)

• Enabling Description: The SLCSE is compiled to run inside a hardware-based secure enclave, such as Intel SGX or AMD SEV. When an application is loaded, a special loader module initiates the enclave and loads the SLCSE code and data into the protected memory region. The application communicates with the SLCSE through a trusted "ECALL" interface, and the SLCSE communicates with the outside world through "OCALLs" that exit the enclave to request services (like network I/O) from the untrusted host application and OS. This provides cryptographic guarantees of isolation and integrity, ensuring that even a compromised host OS cannot tamper with the state of the critical system element. For example, a cryptographic key manager SLCSE could run within an enclave, guaranteeing that private keys are never exposed in plaintext to the main application or the OS.

• Mermaid.js Diagram:

  graph TD
      subgraph "CPU (Hardware Boundary)"
          subgraph "User Process (Untrusted)"
              App["Application Code"]
              OS_Proxy["OS Proxy Lib"]
              App -- "ECALL (Trusted Call)" --> SGX_Enclave
          end
          
          subgraph SGX_Enclave [Secure Enclave (Encrypted Memory)]
              SLCSE["SLCSE Code & Data (e.g., SSL/TLS Stack)"]
              SLCSE -- "OCALL (Untrusted Call)" --> OS_Proxy
          end
      end
  
      subgraph Kernel
          KernelDriver["OS Kernel"]
      end
  
      OS_Proxy -- "System Call" --> KernelDriver
  

Axis 2: Operational Parameter Expansion

Derivative 2.1: Critical System Elements for Hard Real-Time Systems (RTOS)

• Enabling Description: This variation is implemented in a hard real-time operating system (RTOS) like QNX or VxWorks. A high-priority control loop task (e.g., for a robot arm) requires deterministic network communication. To avoid jitter from the system's general-purpose TCP/IP stack, this task dynamically links its own instance of a real-time, lightweight UDP stack as an SLCSE. This SLCSE is designed with lock-free data structures and a pre-allocated memory pool to ensure all operations complete within a bounded time (worst-case execution time). It communicates with the network device driver via a zero-copy, shared-memory queue, bypassing the kernel's standard socket layer. This isolates the timing behavior of the critical task from all other lower-priority network activities on the system.

• Mermaid.js Diagram:

  stateDiagram-v2
      direction LR
      [*] --> Idle
      
      state Task_A_Context {
          direction LR
          state "High Priority Task (Robot Control)" as HPT
          state "RT-UDP Stack SLCSE" as RT_UDP
          HPT --> RT_UDP : send_data()
          RT_UDP --> HPT : return (WCET < 20us)
      }
      
      state Task_B_Context {
          direction LR
          state "Low Priority Task (Logging)" as LPT
          state "Kernel TCP/IP Stack" as K_TCP
          LPT --> K_TCP : send_log()
          K_TCP --> LPT : return (non-deterministic)
      }
  
      Idle --> Task_A_Context : Timer Interrupt
      Task_A_Context --> Idle : Execution Complete
      Idle --> Task_B_Context : Idle Time
      Task_B_Context --> Idle : Execution Complete
  

Derivative 2.2: Ephemeral CSEs for Function-as-a-Service (FaaS) Platforms

• Enabling Description: In a serverless/FaaS environment, each function execution requires isolated access to a database. Instead of a shared connection pool, the FaaS runtime injects a purpose-built, ephemeral database connection SLCSE into the function's execution environment upon invocation. This SLCSE is pre-configured with the specific credentials and connection string for that function. It establishes a connection, manages transactions, and is completely destroyed when the function terminates. This architecture provides perfect isolation between function invocations, preventing credential leakage or transactional state interference. The SLCSE can be optimized for rapid startup and teardown, a critical performance metric in FaaS platforms.

• Mermaid.js Diagram:

  sequenceDiagram
      participant FaaS_Orchestrator
      participant FaaS_Worker
      participant Function_Instance
      participant DB_SLCSE as "Ephemeral DB SLCSE"
      participant Database
  
      FaaS_Orchestrator->>FaaS_Worker: InvokeFunction('myFunc')
      FaaS_Worker->>Function_Instance: Create Process
      FaaS_Worker->>DB_SLCSE: Instantiate and Inject
      Function_Instance->>DB_SLCSE: getConnection()
      DB_SLCSE->>Database: Authenticate & Connect
      Database-->>DB_SLCSE: Connection Handle
      DB_SLCSE-->>Function_Instance: Return Handle
      Function_Instance->>DB_SLCSE: Execute Query
      DB_SLCSE->>Database: Run SQL
      Database-->>DB_SLCSE: Results
      DB_SLCSE-->>Function_Instance: Return Results
      Function_Instance-->>FaaS_Worker: Execution Complete
      FaaS_Worker->>DB_SLCSE: Terminate & Destroy
      FaaS_Worker->>Function_Instance: Destroy Process
  

Axis 3: Cross-Domain Application

Derivative 3.1: Automotive - ADAS vs. In-Vehicle Infotainment (IVI)

• Enabling Description: An automotive computing platform based on Automotive Grade Linux runs two applications with different safety requirements: a safety-critical ADAS application (ASIL D) and a non-critical IVI application (ASIL B). Both need access to the vehicle's CAN bus. The ADAS application links a certified, read-only, statically-analyzed CAN bus driver SLCSE that has been formally verified. The IVI system links a separate, full read-write CAN bus driver SLCSE that allows it to send diagnostic or control messages. Both SLCSE instances communicate with a kernel-level resource manager that arbitrates physical access to the CAN controller hardware, ensuring the ADAS application's messages are always prioritized and that the IVI application cannot send messages that would interfere with critical vehicle functions.

• Mermaid.js Diagram:

  graph TD
      subgraph "ADAS Process (ASIL D)"
          ADAS_App["ADAS Logic"]
          CAN_SLCSE_RO["Certified Read-Only CAN Stack"]
          ADAS_App --> CAN_SLCSE_RO
      end
  
      subgraph "IVI Process (ASIL B)"
          IVI_App["Infotainment UI"]
          CAN_SLCSE_RW["Read-Write CAN Stack"]
          IVI_App --> CAN_SLCSE_RW
      end
      
      subgraph "Kernel Mode"
          Kernel_Arbiter["CAN Bus Kernel Arbiter"]
          CAN_HW["CAN Bus Hardware"]
          Kernel_Arbiter --> CAN_HW
      end
  
      CAN_SLCSE_RO -- "High-Priority Queue" --> Kernel_Arbiter
      CAN_SLCSE_RW -- "Low-Priority Queue" --> Kernel_Arbiter
  

Derivative 3.2: Aerospace - Modular Flight Control Systems

• Enabling Description: An Integrated Modular Avionics (IMA) system hosts two distinct applications on a single processing module: a Flight Management System (FMS) and an Autopilot system. Both communicate over an ARINC 429 data bus. To ensure partitioning, the FMS application links arinc429_fms.so, an SLCSE configured only for the specific ARINC 429 labels relevant to flight planning. The Autopilot application links arinc429_ap.so, a different SLCSE configured for labels related to flight surface actuation. A kernel-level driver manages the physical ARINC 429 transceiver, but it exposes separate device contexts to each SLCSE, which enforce hardware-based label filtering. A write attempt by the FMS application using an Autopilot label will be rejected by the kernel driver, providing robust fault containment compliant with DO-178C standards.

• Mermaid.js Diagram:

  classDiagram
      direction LR
      class FMS_Application {
          +executeFlightPlan()
      }
      class Autopilot_Application {
          +stabilizeAircraft()
      }
      class ARINC429_FMS_SLCSE {
          <<Library>>
          -allowed_labels: Set<Labels>
          +transmit(label, data)
      }
      class ARINC429_AP_SLCSE {
          <<Library>>
          -allowed_labels: Set<Labels>
          +transmit(label, data)
      }
      class Kernel_ARINC429_Driver {
          -device_context: Map<Process, Config>
          +register(process, config)
          +write(process, label, data)
      }
  
      FMS_Application ..> ARINC429_FMS_SLCSE : links
      Autopilot_Application ..> ARINC429_AP_SLCSE : links
      ARINC429_FMS_SLCSE ..> Kernel_ARINC429_Driver : uses
      ARINC429_AP_SLCSE ..> Kernel_ARINC429_Driver : uses
  

Axis 4: Integration with Emerging Technology

Derivative 4.1: AI-Driven Dynamic CSE Optimization

• Enabling Description: A database application is instrumented with a monitoring agent. An AI/ML model, trained on performance counter data (e.g., I/O latency, cache hit rates), analyzes the application's workload in real-time. If the model detects a shift from a transactional (OLTP) to an analytical (OLAP) workload, it predicts that a different file system layout or caching strategy would be more performant. It instructs a control plane to trigger a hot-swap of the application's file system SLCSE. The system quiesces I/O, unlinks the current fs_oltp.so library, and dynamically links a new fs_olap.so library that implements a columnar storage access pattern. This dynamic, AI-driven adaptation optimizes performance without restarting the application.

• Mermaid.js Diagram:

  sequenceDiagram
      participant App as Database App
      participant Agent as Monitoring Agent
      participant AI_Model as AI/ML Model
      participant Controller as Control Plane
      
      loop Real-time
          App->>Agent: Stream Perf. Counters
          Agent->>AI_Model: Send Metrics
          AI_Model->>AI_Model: Analyze Workload
          alt Workload Shift Detected
              AI_Model->>Controller: Recommend CSE: 'fs_olap.so'
              Controller->>App: Signal Quiesce I/O
              Controller->>App: dlclose('fs_oltp.so')
              Controller->>App: dlopen('fs_olap.so')
              Controller->>App: Signal Resume I/O
          end
      end
  

Derivative 4.2: Blockchain-Verified CSE Provenance

• Enabling Description: In a regulated environment (e.g., medical devices), software integrity is paramount. Before an application is allowed to load, a trusted loader module computes the cryptographic hash of the designated SLCSE file (e.g., dicom_parser_v3.1.so). It then queries a private blockchain/distributed ledger using the SLCSE's name and version as a key. The transaction record on the blockchain contains the official, vendor-certified hash for that library version. If the computed hash matches the hash on the ledger, the loader proceeds to link the library. If not, the application launch is aborted, and an immutable audit event is logged to the blockchain, preventing the execution of tampered or unauthorized critical system code.

• Mermaid.js Diagram:

  graph TD
      A[Start Application Load] --> B{Compute Hash of SLCSE file};
      B --> C{Query Blockchain for Certified Hash};
      C --> D{Hashes Match?};
      D -- Yes --> E[Link SLCSE & Continue];
      D -- No --> F[Abort Load & Log Audit Event];
      F --> G[End];
      E --> G[End];
  

Axis 5: The "Inverse" or Failure Mode

Derivative 5.1: Graceful Degradation via Fallback CSE

• Enabling Description: A web server application links a high-performance, feature-rich network stack SLCSE (http_stack_accel.so) that uses kernel-bypass features. A health-monitoring thread within the application periodically checks the sanity of this SLCSE. If the health check fails (e.g., a memory corruption is detected), the monitor triggers a graceful fallback. It uses the dlsym and dlopen APIs to dynamically re-route the application's function pointers for send(), recv(), etc., from the failed SLCSE to a pre-loaded, simple, and robust fallback SLCSE (http_stack_safe.so). This safe version uses standard, stable kernel system calls. The application continues to run, serving basic requests with higher latency, instead of crashing completely.

• Mermaid.js Diagram:

  stateDiagram-v2
      state "Running (High Performance)" as HP
      state "Running (Degraded Mode)" as DM
      state "Crashed" as CR
  
      [*] --> HP : Initial Load
      HP: Uses `http_stack_accel.so`
  
      HP --> DM : Health Check Fails
      DM: Re-links to `http_stack_safe.so`
  
      HP --> CR : Unhandled Exception
      DM --> HP : Manual Reset / Recovery
  

Combination Prior Art Scenarios with Open-Source Standards

1. Combination with Docker/OCI and LD_PRELOAD: An OCI-compliant runtime like runc is modified to accept a custom annotation in the config.json file, specifying an application-specific network stack SLCSE. When creating the container, the runtime uses the LD_PRELOAD environment variable within the new container's namespace to force the application to load this specified library (e.g., LD_PRELOAD=/opt/lib/fast-stack.so). This fast-stack.so implements standard socket APIs but directs traffic to a user-mode network device (like AF_XDP), bypassing the kernel's network stack for that container only. This provides container-specific network behavior on a shared host kernel.

2. Combination with Kubernetes and a Service Mesh Sidecar (Istio): The Istio service mesh injects its proxy (Envoy) not as a separate container but as an SLCSE (libenvoy.so) directly into the application's pod. The Pod spec includes a field for the Envoy configuration. The Kubelet, via a custom Container Runtime Interface (CRI) implementation, mounts the library and config into the container and uses dynamic linking mechanisms to load it. The library overrides standard networking calls (connect, send, recv) to transparently apply all mTLS encryption, traffic routing, and telemetry policies within the application's own process, eliminating the localhost network hop and reducing latency.

3. Combination with QEMU/KVM and VirtIO: A guest VM running on a KVM hypervisor is provisioned with a standard para-virtualized VirtIO network device. A high-performance computing (HPC) application running inside the guest, however, requires lower latency. The application links a custom libvirtio-net-user.so SLCSE. This library communicates with a special character device exposed by the guest's VirtIO driver. Using ioctl calls, it maps the VirtIO device's virtqueues directly into the application's user-mode address space. The application can now place network packets directly onto the virtqueue and signal the hypervisor via an eventfd, completely bypassing the guest kernel's network stack for all its data path operations.