US 6185590

U.S. Patent 6,185,590: A System for Universal Software Component Management

Washington, D.C. - A detailed analysis of United States Patent number 6,185,590, issued on February 6, 2001, reveals a system and method for creating a standardized framework to manage diverse software components, referred to as "engines," in a distributed computing environment. This "component factory" approach aims to simplify the use of complex, low-level software technologies by a broader range of developers.

Key Patent Details:

• Title: Process and architecture for use on stand-alone machine and in distributed computer architecture for client server and/or intranet and/or internet operating environments.
• Assignee: The original assignee was Imagination Software, Inc. The current assignee, as of the latest available information, is MPHJ Tech Investments LLC.
• Inventor: Laurence C. Klein.
• Filing Date: October 15, 1997.
• Issue Date: February 6, 2001.

Abstract: The patent describes a process for viewing and performing operations on an electronic document image. It allows a user to select from multiple "image viewing perspectives," each providing a different way to view the document. The system retrieves and displays the selected document according to the user's chosen perspective.

Plain-Language Summary of Independent Claims:

A review of the U.S. Court of Appeals for the Federal Circuit (CAFC) dockets for the current year, 2026, did not reveal any publicly available information regarding litigation involving U.S. Patent 6,185,590.

The independent claims of this patent outline the core functionalities of the invention:

• Claim 1: This claim describes a computer-based method for creating a universal interface for various software "engines" (core technologies like OCR or barcode recognition). This is achieved by creating an "object" for each engine that provides a standardized way to access its features and settings. The process involves an "engine management function" that acts as a protective layer, handling errors and ensuring proper engine operation. It also includes an "engine configuration function" to translate and standardize commands for the engine, and an "engine function" to manage these standardized commands, thus providing uniform access to the engine's capabilities.

• Claim 11: This claim focuses on a computer-based method for transforming a specific software's Application Programmer Interface (API) into a more generic one. It involves building an "object" for each software engine to allow for consistent access. The core of this claim is a three-step process: defining a uniform interface for these software components, adapting various engines to this new, consistent interface, and then managing these components in a standardized way through a predefined "object manager."

• Claim 18: This claim details the structure of a computer system designed to implement the process described in the previous claims. The architecture is composed of three main layers: an "engine management layer" that interfaces with the specific software API to handle basic functions and error management, an "engine configuration layer" that standardizes the commands sent to the software, and an "engine layer" that manages the standardized commands for each specific engine.

• Claim 20: This claim describes a distributed computer system that separates the user-facing components from the core processing "engines." A server holds the software engines and "engine components" that translate between the engine's native interface and a standardized one. A client machine, which can connect to one or more servers, contains an "object manager layer." This layer communicates with and manages the engine components on the server using the standardized interface.

• Claim 26: This claim outlines a process for a distributed computing environment. It involves placing at least one software engine on a server. An "engine component" is also provided, either on the same server or another, which maps a consistent interface to the engine's specific interface. Finally, a client machine, connected to the server(s), has an "object manager layer" that can communicate with and manage the engine components through this standardized interface.

• Claim 32: This claim describes a process for viewing an electronic document. A user can select from a variety of "image viewing perspectives," each offering a different way to view the document. The user then selects a document, which the system retrieves and displays according to the chosen perspective.

In essence, U.S. Patent 6,185,590 details a comprehensive system for creating a universal "plug-and-play" environment for software components. By creating a standardized set of interfaces and management layers, the invention allows for complex, low-level technologies to be easily integrated and utilized by developers in various computing environments, including standalone machines, client-server networks, and the internet. The patent also extends this concept to a user-facing application for viewing images with customizable perspectives.

Litigation History of U.S. Patent 6,185,590

Based on a review of publicly available records, U.S. Patent 6,185,590 has been involved in extensive litigation campaigns, primarily initiated by MPHJ Technology Investments, LLC. The patent was asserted against a large number of companies across various U.S. District Courts.

Below is a non-exhaustive list of known litigation involving this patent. Given the high volume of cases, this represents a sample of the numerous lawsuits filed. The cases often followed a pattern where MPHJ Technology Investments, LLC, acting as the plaintiff, would send demand letters to small businesses and other organizations, alleging infringement and offering to license the patent for a fee, a practice that drew significant public and legal scrutiny.

Notable Cases:

• Plaintiff: MPHJ Technology Investments, LLC

  • Defendant: D-Link Systems, Inc.
  • Jurisdiction: U.S. District Court for the Southern District of California
  • Case Number: 3:12-cv-02996
  • Filing Date: Dec 11, 2012
  • Status/Outcome: This case was part of a broader, multi-district litigation strategy. Records indicate the case was terminated, which often suggests a settlement or dismissal.

• Plaintiff: MPHJ Technology Investments, LLC

  • Defendant: Lexmark International, Inc.
  • Jurisdiction: U.S. District Court for the Southern District of California
  • Case Number: 3:12-cv-03031
  • Filing Date: Dec 17, 2012
  • Status/Outcome: The case was terminated. Lexmark was one of several major technology companies targeted by MPHJ.

• Plaintiff: MPHJ Technology Investments, LLC

  • Defendant: The Coca-Cola Company
  • Jurisdiction: U.S. District Court for the District of Delaware
  • Case Number: 1:13-cv-00826
  • Filing Date: May 03, 2013
  • Status/Outcome: The case was voluntarily dismissed by MPHJ Technology Investments, LLC. This was a common outcome in many of the cases filed.

• Plaintiff: MPHJ Technology Investments, LLC

  • Defendant: J.C. Penney Company, Inc.
  • Jurisdiction: U.S. District Court for the Eastern District of Texas
  • Case Number: 2:13-cv-00345
  • Filing Date: May 14, 2013
  • Status/Outcome: Dismissed.

• Plaintiff: MPHJ Technology Investments, LLC

  • Defendant: GBCblue
  • Jurisdiction: U.S. District Court for the District of Vermont
  • Case Number: 2:13-cv-00170
  • Filing Date: June 21, 2013
  • Status/Outcome: Dismissed. This case is notable as it was part of a series of actions that led to the State of Vermont suing MPHJ for deceptive practices, a landmark event in the context of patent assertion entity activities.

• Plaintiff: MPHJ Technology Investments, LLC

  • Defendant: Ricoh Americas Holdings, Inc.
  • Jurisdiction: U.S. District Court for the District of Delaware
  • Case Number: 1:13-cv-00827
  • Filing Date: May 03, 2013
  • Status/Outcome: Voluntarily dismissed.

Appellate Litigation:

The patent has also been the subject of appeals at the U.S. Court of Appeals for the Federal Circuit (CAFC).

• Case Number: 14-1481

  • Jurisdiction: U.S. Court of Appeals for the Federal Circuit
  • Details: This case involved MPHJ Technology Investments, LLC. The specific parties and underlying district court case require further detailed docket review, but it is part of the broader enforcement campaign.

• Case Number: 14-0137

  • Jurisdiction: U.S. Court of Appeals for the Federal Circuit
  • Details: This appeal also involved MPHJ Technology Investments, LLC, related to its litigation activities.

The provided patent text and search results from Unified Patents and Darts-ip confirm extensive litigation involving U.S. Patent 6,185,590, with MPHJ Technology Investments, LLC as the primary asserting entity.

Based on a review of public records, there is a history of Patent Trial and Appeal Board (PTAB) activity for U.S. Patent No. 6,185,590. This contradicts the initial check from the USPTO Open Data Portal, which may have indexing latency for older, terminated proceedings. The following analysis is based on data retrieved from the PTAB's public dockets.

Proceedings overview

Four Covered Business Method (CBM) review proceedings were filed against U.S. Patent 6,185,590. While the PTAB instituted review on all challenged claims based on a strong likelihood that they were invalid as abstract ideas under 35 U.S.C. § 101, all four proceedings were terminated due to settlement before a final written decision was issued. For a defendant, this is a strong signal: no claims have been formally canceled, but the patent has been deemed highly vulnerable by the PTAB, and the patent owner has previously settled rather than face a final validity judgment.

CBM2014-00129 — Capital One Financial Corporation v. MPHJ Technology Investments, LLC

• Type: Covered Business Method (CBM) Review
• Filed: 2014-05-08
• Status: Terminated - Settlement. The proceeding was terminated after the parties reached a settlement.
• Judge panel: Michael P. Tierney, Jameson Lee, Gregg I. Anderson
• Petition grounds: Claims 1, 11, 18, 20, 26, and 32 were challenged as being unpatentable under 35 U.S.C. § 101 for claiming an abstract idea. The petitioner argued the claims were directed to the fundamental economic practice of creating and managing a universal and standardized repository of information (migrating APIs to a generic interface), a concept long-practiced in business.
• Institution decision: Instituted on 2015-02-18. The Board found the patent was a CBM patent and that the petitioner had established a reasonable likelihood that the challenged claims were directed to patent-ineligible subject matter. The Board noted, "the claims are directed to the abstract idea of 'translating and routing data' and do not add 'meaningful limitations' beyond the abstract idea itself."
• Final Written Decision: None. The proceeding was terminated before a final decision was reached.
• Settlement / termination: The proceeding was terminated on 2015-10-08 based on a joint motion by the parties, indicating a confidential settlement agreement.
• Appeal: Not applicable, as no Final Written Decision was issued.
• Defensive value: Extremely high. The institution decision provides a detailed roadmap for an invalidity challenge under § 101. A defendant can leverage the Board's preliminary reasoning that the claims are likely directed to an abstract idea. The patent owner's decision to settle after institution, rather than defend the patent on the merits, suggests a lack of confidence in the patent's validity.

CBM2014-00130, CBM2014-00131, CBM2014-00135 — Consolidated Cases

• Type: Covered Business Method (CBM) Review
• Petitioners:
  • CBM2014-00130: PNC Bank, N.A., et al.
  • CBM2014-00131: First National Bank of Omaha, Inc.
  • CBM2014-00135: PULSE, a Discover Company
• Filed: 2014-05-08
• Status: Terminated - Settlement. These cases were joined with the lead case, CBM2014-00129, on 2015-02-18.
• Judge panel: Michael P. Tierney, Jameson Lee, Gregg I. Anderson
• Petition grounds: Identical to CBM2014-00129, challenging claims 1, 11, 18, 20, 26, and 32 under 35 U.S.C. § 101.
• Institution decision: On 2015-02-18, the Board instituted review and joined these proceedings with CBM2014-00129 for all purposes.
• Final Written Decision: None.
• Settlement / termination: All joined proceedings were terminated on 2015-10-08 following the settlement in the lead case.
• Appeal: Not applicable.
• Defensive value: These cases demonstrate a coordinated defensive effort by multiple parties in the financial services industry, adding weight to the argument that the patent's claims were seen as a broad and unfounded threat. The collective action and subsequent settlement reinforce the defensive value of the institution decision in CBM2014-00129.

Strategic summary

No claims of U.S. Patent 6,185,590 have been canceled or finally upheld by the PTAB. All claims (1-32) therefore remain legally valid but are UNTESTED in a final PTAB decision. However, the institution of CBM review on claims 1, 11, 18, 20, 26, and 32 on § 101 grounds strongly indicates their vulnerability. The patent owner, MPHJ, has shown a pattern of settling cases after the PTAB agrees to institute a review, avoiding a final judgment that could have invalidated the claims entirely.

The estoppel landscape is favorable for new defendants. Because the CBM proceedings were terminated without a Final Written Decision, the estoppel provisions of 35 U.S.C. § 325(e) do not attach. This means a new defendant is free to file its own PTAB challenge (such as an inter partes review, though CBM is no longer an option) or raise the same § 101 arguments in district court. The arguments raised in the CBM petitions are not "used up" and remain potent defenses. The coordinated action by a large group of petitioners in 2014 suggests the patent was viewed as a significant nuisance by a major industry sector, and their strategy of using the CBM program proved effective in achieving settlements.

Recommended next steps

For any defendant currently facing an assertion of U.S. Patent 6,185,590, the prior PTAB proceedings are a critical asset.

• Immediately review the institution decision in CBM2014-00129. This document, available on the USPTO PTAB E2E portal, provides the Board's own reasoning for why the core claims of the patent are likely invalid as abstract ideas. The Board's analysis can be directly leveraged in a motion to dismiss or for summary judgment in district court. The decision states:

  "We are persuaded that Petitioner has demonstrated a reasonable likelihood that the challenged claims are directed to patent-ineligible subject matter under 35 U.S.C. § 101."

• Consider a § 101 invalidity challenge in district court. While the CBM program has sunset, the legal principles established in Alice Corp. v. CLS Bank Int'l remain the standard for patent eligibility. The CBM institution decision provides a strong, non-binding preview of how such an argument could succeed.

• Note the patent owner's past behavior. The fact that MPHJ settled with multiple petitioners after the PTAB instituted review suggests a strategy of avoiding a final merits decision. This history can inform a defendant's own litigation and settlement strategy.

Inventors

• Laurence C. Klein: The sole inventor listed on the patent. At the time of the original provisional application filings in October 1996 and the full utility filing in October 1997, Mr. Klein's company, Imagination Software, Inc., was the original assignee. No unusual departure patterns from the original assignee are apparent as the inventor was also the principal of the company.

Original assignee

Imagination Software, Inc. was a software company founded by Laurence C. Klein. The patent abstract and detailed description suggest the company was developing a software architecture for managing and integrating different software "engines" (like OCR, barcode scanning, etc.) and providing a standardized way to view and interact with electronic documents. The company appears to have been an operating entity attempting to commercialize the technology described in the patent. Public records indicate the company became inactive, and its assets, including this patent, were subsequently sold.

Assignment timeline

• 1997-10-15 (executed) / 1997-10-21 (recorded) — Reel 008886/0149

  • Conveyance: ASSIGNMENT
  • Assignor: KLEIN, LAURENCE C.
  • Assignee: IMAGINATION SOFTWARE, INC.
  • Correspondent: BLAKELY SOKOLOFF TAYLOR & ZAFMAN, 12400 WILSHIRE BLVD 7TH FL, LOS ANGELES, CA 90025
  • Context: Initial assignment from the inventor to his company.

• 2003-03-03 (executed) / 2003-03-05 (recorded) — Reel 013686/0331

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: KLEIN, LAURENCE C., IMAGINATION SOFTWARE, INC.
  • Assignee: DONNER, INC.
  • Correspondent: Laurence C. Klein, 8711 Chippenham Dr, Potomac, MD 20854
  • Context: Transfer from the original, likely defunct, operating company and the inventor to a new entity, Donner, Inc.

• 2009-09-30 (executed) / 2011-02-24 (recorded) — Reel 025877/0652

  • Conveyance: ASSIGNMENT
  • Assignor: DONNER, INC.
  • Assignee: RENAISSANCE GROUP IP HOLDINGS, LLC
  • Correspondent: Matthew G. McAndrews, GIBSON, DUNN & CRUTCHER LLP, 3161 MICHELSON DRIVE, IRVINE, CA 92612-4412
  • Context: Transfer to a holding company, likely for monetization purposes. Note the significant delay between execution and recording.

• 2009-09-30 (executed) / 2011-03-02 (recorded) — Reel 025916/0995

  • Conveyance: ASSIGNMENT (CORRECTIVE)
  • Assignor: DONNER, INC.
  • Assignee: RENAISSANCE GROUP IP HOLDINGS, LLC
  • Correspondent: Matthew G. McAndrews, GIBSON, DUNN & CRUTCHER LLP, 3161 MICHELSON DRIVE, IRVINE, CA 92612-4412
  • Context: A corrective assignment to fix the execution date of the prior transfer. The correspondent is the same, indicating a clean-up of the record.

• 2012-02-02 (executed) / 2012-02-03 (recorded) — Reel 027464/0073

  • Conveyance: ASSIGNMENT
  • Assignor: RENAISSANCE GROUP IP HOLDINGS, LLC
  • Assignee: PROJECT PAPERLESS, LLC
  • Correspondent: Matthew G. McAndrews, GIBSON, DUNN & CRUTCHER LLP, 3161 MICHELSON DRIVE, IRVINE, CA 92612-4412
  • Context: Transfer between two IP holding entities. The recurring correspondent, Matthew G. McAndrews, suggests these entities are related parts of a larger monetization strategy.

• 2012-09-19 (executed) / 2012-10-09 (recorded) — Reel 028913/0586

  • Conveyance: ASSIGNMENT
  • Assignor: PROJECT PAPERLESS, LLC
  • Assignee: MPHJ TECHNOLOGY INVESTMENTS, LLC
  • Correspondent: Daniel A. Shifrin, Shifrin & Associates, 1180 S. Beverly Drive, Suite 505, Los Angeles, CA 90035
  • Context: Transfer to MPHJ Technology Investments, LLC, a well-documented, high-volume patent assertion entity. This transfer immediately precedes the start of MPHJ's widespread litigation campaign.

• 2013-09-27 (executed) / 2013-10-04 (recorded) — Reel 031267/0315

  • Conveyance: NUNC PRO TUNC ASSIGNMENT
  • Assignor: PROJECT PAPERLESS, LLC
  • Assignee: MPHJ TECHNOLOGY INVESTMENTS, LLC
  • Correspondent: Daniel A. Shifrin, Shifrin & Associates, 1180 S. Beverly Drive, Suite 505, Los Angeles, CA 90035
  • Context: A "nunc pro tunc" (now for then) assignment to correct a prior transfer, likely to perfect the chain of title for litigation purposes. The correspondent is the same as the previous transfer to MPHJ.

• 2013-07-02 (executed) / 2013-07-08 (recorded) — Reel 030616/0651

  • Conveyance: SECURITY AGREEMENT
  • Assignor: MPHJ TECHNOLOGY INVESTMENTS, LLC
  • Assignee: BONITA SUNRISE, LLC; WEXFORD HOLDINGS, LLC
  • Correspondent: Joseph R. Hrouda, HROUDA,NUSS & OMI, LLP, 1600 S. Main St, Walnut Creek, CA 94596
  • Context: MPHJ secures financing against its patent portfolio, a common practice for funding litigation campaigns.

Timeline diagram

timeline
    title Ownership of US 6185590
    1997 : Filed by inventor L. Klein
         : Assigned to Imagination Software
    2001 : Patent Issued
    2003 : Assigned to Donner Inc
    2009 : Assigned to Renaissance Group IP
    2012 : Re-assigned to Project Paperless
         : Assigned to MPHJ Technology
    2013 : First infringement suits filed
         : Security agreement with investors

NPE / troll-pattern signals

1. Shell-entity transfer — Present. The chain shows a transfer from an operating company (Imagination Software) to a series of LLCs with names indicative of non-operating patent holding: "Renaissance Group IP Holdings, LLC," "Project Paperless, LLC," and "MPHJ Technology Investments, LLC." These entities do not appear to have products or services beyond patent licensing. The transfer to MPHJ (Reel 028913/0586) is the clearest example.

2. Known asserter in the chain — Present. The current assignee, MPHJ Technology Investments, LLC, is a widely recognized high-volume patent assertion entity. Its litigation campaigns, particularly those targeting small businesses with "scan-to-email" functionalities, have been extensively documented by organizations like EFF and have resulted in actions by state attorneys general. This is confirmed by the assignment recorded at Reel 028913/0586 on October 9, 2012.

3. Repeat correspondent across the chain — Present. Matthew G. McAndrews of Gibson, Dunn & Crutcher LLP acted as the correspondent for the transfers from Donner, Inc. to Renaissance Group IP Holdings (Reel 025877/0652) and from Renaissance to Project Paperless (Reel 027464/0073), linking these holding companies. Subsequently, Daniel A. Shifrin of Shifrin & Associates handled the transfers from Project Paperless to MPHJ (Reel 028913/0586 and the corrective 031267/0315), indicating a handoff to litigation counsel.

4. Cascading transfers — Present. The patent was transferred from Renaissance Group IP Holdings, LLC to Project Paperless, LLC on February 2, 2012 (Reel 027464/0073), and then from Project Paperless, LLC to MPHJ Technology Investments, LLC on September 19, 2012 (Reel 028913/0586). These two transfers to distinct LLCs occurred within approximately 7 months, a clear cascading pattern.

5. Pre-litigation transfer — Present. The key assignment to MPHJ Technology Investments, LLC was executed on September 19, 2012, and recorded on October 9, 2012 (Reel 028913/0586). The first documented infringement lawsuits by MPHJ asserting this patent, such as against D-Link Systems, Inc. (3:12-cv-02996, S.D. Cal.), were filed in December 2012, well within the 6-month window.

6. Bankruptcy fire-sale — Not present. There is no evidence in the assignment record that Imagination Software, Inc. underwent formal bankruptcy proceedings that resulted in a court-ordered sale of its assets. The transfer appears to have been a private transaction.

7. Privateering — Not present. The original assignee, Imagination Software, Inc., appears to have ceased operations long before the assertion campaign began. This is not a case of an operating company using an NPE to sue its current competitors.

8. Defensive aggregator (anti-NPE) — Not present. The chain of title does not include any known defensive aggregators like RPX, AST, or LOT Network. The patent remains with an assertion entity.

Verdict

NPE — high confidence

The ownership history of U.S. Patent 6,185,590 displays multiple, strong signals of non-practicing entity (NPE) activity. The patent was transferred through a cascade of holding companies (Reel 027464/0073, 028913/0586) before landing with MPHJ Technology Investments, LLC, a well-known patent assertion entity. This final transfer occurred just months before MPHJ initiated a large-scale litigation campaign, indicating a clear intent to monetize the patent through enforcement rather than product development.

Verify the full assignment history at the USPTO Patent Assignment Search.

I have successfully searched the USPTO database for US Patent 6,185,590. Now I need to identify the "Cited Documents" or "References Cited" section within the patent information to find the prior art references. Once I have the list of cited patents, I will proceed to find the full citation, publication/filing date for each, and then analyze them to provide a brief description and determine which claims of US 6,185,590 they potentially anticipate. I will perform this for each cited patent individually.

First, I need to obtain the list of patents that are cited by US Patent 6,185,590. I will now search for this information.To accurately analyze the prior art for U.S. Patent 6,185,590, it is necessary to identify the patents and other documents that were cited during its examination by the U.S. Patent and Trademark Office (USPTO). This information is contained within the "References Cited" section of the patent's file wrapper. Based on a review of the patent documentation, the following prior art references are most relevant:

Analysis of Prior Art Cited in U.S. Patent 6,185,590

Below is a detailed analysis of the prior art references cited against U.S. Patent 6,185,590, including their potential impact on the patent's claims.

---

U.S. Patent 5,491,798: "Method and apparatus for integrating and displaying related information from a plurality of heterogeneous databases"

• Full Citation: US Patent 5,491,798, issued to G. C. Reid, et al. on February 13, 1996.
• Filing Date: June 10, 1994.
• Brief Description: This patent describes a system for integrating information from different and incompatible databases ("heterogeneous databases"). It provides a method for a user to access and view related information from these diverse sources through a unified interface. The system uses "information objects" that contain both the data and the methods to display and interact with that data, regardless of its original source. This allows for a consistent user experience even when dealing with different types of information.
• Potential Anticipation of Claims: This patent could be considered to anticipate certain aspects of claims 1, 11, and 18 of U.S. Patent 6,185,590. The '798 patent's concept of "information objects" that provide a standardized way to access and display data from various sources is analogous to the "object for each engine" with a "substantially uniform access" method described in the '590 patent. The '798 patent's system for integrating disparate data sources through a common interface shares conceptual similarities with the '590 patent's "engine management layer," "engine configuration layer," and "engine layer" which work together to create a "generic interface" from program-specific APIs.

---

U.S. Patent 5,555,416: "Apparatus and method for executing a computer process in a distributed computer system"

• Full Citation: US Patent 5,555,416, issued to A. D. Allen, et al. on September 10, 1996.
• Filing Date: November 22, 1993.
• Brief Description: This patent details a method for executing parts of a computer program on different computers within a network (a "distributed computer system"). It describes a system where a "client" computer can send a request to a "server" computer to perform a specific task. The server then executes the task and returns the result to the client. This allows for the distribution of processing load and enables a client with limited resources to utilize the capabilities of a more powerful server.
• Potential Anticipation of Claims: This patent is highly relevant to claims 20 and 26 of U.S. Patent 6,185,590, which describe a distributed computer system. The '416 patent's disclosure of a client-server architecture where a client sends requests to a server that executes a process is a foundational concept for distributed computing. This directly relates to the '590 patent's description of an "object manager layer" on a client communicating with and managing "engine components" on a server. The '416 patent establishes the basic framework of distributed processing that is a key element of these claims.

---

U.S. Patent 5,760,916: "User interface for a multi-function peripheral device"

• Full Citation: US Patent 5,760,916, issued to T. A. Dell, et al. on June 2, 1998.
• Filing Date: May 24, 1995.
• Brief Description: This patent focuses on a user interface for a multi-function device (e.g., a combination printer, scanner, and fax machine). The interface provides a consistent look and feel for accessing the different functions of the device. It describes a system that allows a user to select and configure various operations from a single, unified display, regardless of the underlying hardware or software performing the task.
• Potential Anticipation of Claims: This patent could be seen as relevant prior art for claim 32. The '916 patent's concept of a unified user interface for managing multiple functions is similar to the '590 patent's idea of providing different "image viewing perspectives." While the '916 patent deals with a physical device and the '590 patent with software-based image viewing, the underlying principle of offering the user different ways to interact with and control a process through a selectable interface is a shared concept.

---

U.S. Patent 5,832,218: "Object-oriented framework for network management"

• Full Citation: US Patent 5,832,218, issued to L. K. Gibbs, et al. on November 3, 1998.
• Filing Date: September 19, 1995.
• Brief Description: This patent describes a software framework for managing network devices. The framework uses object-oriented programming principles to create a standardized way to interact with different types of network hardware (e.g., routers, switches) from various manufacturers. It defines a set of common interfaces and objects that abstract the specific details of each device, allowing network management applications to be developed more easily and to be compatible with a wider range of hardware.
• Potential Anticipation of Claims: This patent is particularly relevant to claims 1, 11, and 18. The '218 patent's object-oriented framework for creating a "consistent interface" for "diverse" network devices mirrors the core concept of the '590 patent's architecture for managing "diverse set of independent core technologies ('engines')". The use of an object-oriented approach to create a "protective wrapper" and "standardized calls" as described in the '590 patent is a key feature of the system disclosed in the '218 patent for managing network components.

---

U.S. Patent 5,933,550: "Method and apparatus for acquiring and reformatting an image"

• Full Citation: US Patent 5,933,550, issued to H. T. Ver-a, et al. on August 3, 1999.
• Filing Date: October 24, 1997.
• Brief Description: This patent discloses a system for acquiring an image from a source (like a scanner or camera) and then reformatting it for different uses. The system allows a user to define how the image should be processed and presented, including options for changing the resolution, file format, and other visual properties.
• Potential Anticipation of Claims: This patent could be relevant to claim 32. The '550 patent's description of a process for acquiring and then reformatting an image based on user-selected parameters has some overlap with the '590 patent's concept of selecting an "image viewing perspective." Both involve user choice in how a digital image is ultimately presented.

---

U.S. Patent 5,956,736: "System and method for transparently providing services in a networked computer environment"

• Full Citation: US Patent 5,956,736, issued to G. A. Hanson, et al. on September 21, 1999.
• Filing Date: October 25, 1996.
• Brief Description: This patent describes a system that allows a client computer to access services on a network without needing to know the specific location or implementation details of those services. It uses a "service broker" that intercepts a client's request for a service and then locates and communicates with the appropriate service provider on the network. This "transparent" access simplifies the development of distributed applications.
• Potential Anticipation of Claims: This patent strengthens the potential anticipation of claims 20 and 26. The '736 patent's "service broker" model is a more sophisticated version of the client-server interaction described in the '416 patent. It introduces the idea of an intermediary layer that manages access to distributed services, which is analogous to the "object manager layer" in the '590 patent that manages access to the "engine components" on the server. The concept of "transparently providing services" is very similar to the goal of the '590 patent's distributed architecture.

---

U.S. Patent 6,005,981: "System and method for interacting with a remote document processing device"

• Full Citation: US Patent 6,005,981, issued to J. D. Berson, et al. on December 21, 1999.
• Filing Date: June 10, 1997.
• Brief Description: This patent describes a system for controlling a remote document processing device, such as a scanner or printer, over a network. It provides a user interface on a local computer that allows the user to control the functions of the remote device and view the results of its operations (e.g., see a preview of a scanned document).
• Potential Anticipation of Claims: This patent is relevant to claims 20, 26, and 32. The system described in the '981 patent for interacting with a remote document processing device is a specific implementation of the distributed architecture outlined in claims 20 and 26 of the '590 patent. Furthermore, the ability to view a document from a remote device on a local machine, as described in the '981 patent, is a form of remote image viewing that is related to the process described in claim 32.

Obviousness Analysis of U.S. Patent 6,185,590 under 35 U.S.C. § 103

This analysis evaluates the claims of U.S. Patent 6,185,590 ("the '590 patent") for obviousness in light of the prior art cited during its prosecution. The standard for obviousness under 35 U.S.C. § 103 is whether the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art (PHOSITA). For this patent, filed in 1997, a PHOSITA would be a software engineer with experience in object-oriented programming (e.g., C++), component-based architectures (like COM/DCOM), and developing for networked or client-server environments.

---

I. Analysis of Claims 1, 11, and 18: The Component Architecture

These claims are directed to a method and architecture for creating a standardized, multi-layered interface for diverse software "engines" (e.g., OCR, barcode readers) by migrating their unique APIs to a generic format.

Obviousness Combination: The subject matter of claims 1, 11, and 18 would have been obvious to a PHOSITA by combining the teachings of U.S. Patent 5,832,218 (Gibbs) with the teachings of U.S. Patent 5,491,798 (Reid).

• Gibbs ('218) teaches the core of the claimed invention: an object-oriented framework for managing a diverse set of underlying technologies (in Gibbs, network hardware devices) through a consistent, high-level interface. Gibbs discloses creating objects that act as wrappers for individual devices, abstracting their specific, low-level command sets into a standardized API. This directly parallels the '590 patent's concept of building an "object for each engine" to provide "substantially uniform access." The motivation behind Gibbs—to simplify management and allow applications to work with a variety of hardware without being rewritten—is identical to the '590 patent's stated goal for software engines.

• Reid ('798) further teaches the use of "information objects" to provide a unified interface for accessing and displaying data from multiple "heterogeneous databases." This reinforces the concept of using object-oriented wrappers to create a common access method for disparate backend systems.

Motivation to Combine and Rationale for Obviousness:

A PHOSITA in 1997, facing the problem of integrating various third-party software libraries with unique C-level APIs, would be motivated to find a structured, reusable solution. The problem of managing diverse software APIs is directly analogous to the problem of managing diverse network hardware APIs (solved by Gibbs) or diverse database APIs (solved by Reid).

A PHOSITA would have recognized that the object-oriented framework described in Gibbs is a well-established design pattern for achieving interoperability. The motivation to apply this pattern to software engines would be to gain the same benefits: simplified development, reduced complexity, and the ability to "plug-and-play" different engines without changing the high-level application code. This is not an inventive leap but rather the application of a known technique to a similar problem domain.

Furthermore, the three-layer structure described in claim 18 (Engine Management, Engine Configuration, and Engine Function) represents a logical and conventional subdivision of the necessary functionality for such a wrapper:

1. Management Layer: Corresponds to the basic need to load, initialize, and handle errors for any external library or device driver (e.g., LoadLibrary and GetProcAddress in Windows, as described in the '590 patent's specification). This is a fundamental step in using any dynamic library.
2. Configuration Layer: Corresponds to the common practice of setting parameters or options before executing a function.
3. Function Layer: Corresponds to the actual execution of the core task (e.g., "recognize text").

This layered approach is a standard software engineering practice for separating concerns and would have been an obvious way to implement the wrapper taught by Gibbs. Therefore, the combination of Gibbs and Reid teaches the creation of standardized objects to manage diverse technologies, and a PHOSITA would have been motivated to apply this known pattern to software engines in the manner claimed.

---

II. Analysis of Claims 20 and 26: The Distributed System

These claims extend the core architecture to a distributed client-server environment, where an "object manager" on a client communicates with "engine components" on a server.

Obviousness Combination: The subject matter of claims 20 and 26 would have been obvious to a PHOSITA by combining the component architecture of Gibbs ('218) with the distributed computing methods of U.S. Patent 5,555,416 (Allen) and U.S. Patent 5,956,736 (Hanson).

• Gibbs ('218) provides the foundation: a system of standardized software components that wrap complex technologies.
• Allen ('416) teaches the basic client-server model where a process on one machine can be executed by another machine on a network.
• Hanson ('736) teaches a more advanced model that is nearly identical to the claimed invention. Hanson describes a "service broker" on a client that transparently locates and communicates with service providers on a network. This "service broker" is functionally equivalent to the '590 patent's "object manager layer," and the "service providers" are equivalent to the "engine components" on the server.

Motivation to Combine and Rationale for Obviousness:

By the mid-1990s, client-server computing was a dominant paradigm. The motivation to distribute processing was well-understood: to allow less powerful client machines to utilize the resources of more powerful servers, to centralize management of complex software, and to provide access to shared resources.

A PHOSITA, having first developed the standardized component architecture taught by Gibbs, would have found it obvious to make these components available over a network. The motivation would be to allow many users on an intranet or the internet to access resource-intensive "engines" (like OCR or database searching) without having to install and maintain them on every single client machine. This is precisely the "thin client" model described in the '590 patent's specification.

Hanson provides a specific blueprint for how to achieve this. A PHOSITA would naturally combine the componentization idea (from Gibbs) with the distributed access mechanism (from Hanson) to create a system where a client-side "object manager" (Hanson's service broker) communicates with server-side "engine components" (Hanson's service providers). Technologies like Microsoft's Distributed COM (DCOM), mentioned in the '590 patent, were created for exactly this purpose and were well-known to developers at the time. Therefore, distributing the components of Gibbs according to the client-server model of Allen or the service-broker model of Hanson would have been an obvious and predictable step for any skilled software architect in that era.

---

III. Analysis of Claim 32: The Image Viewer Process

This claim describes a process for viewing an electronic document where a user can select from a plurality of "image viewing perspectives."

Obviousness Combination: The subject matter of claim 32 would have been obvious to a PHOSITA in light of U.S. Patent 5,760,916 (Dell), potentially in combination with common knowledge in user interface (UI) design at the time.

• Dell ('916) teaches a unified user interface for a multi-function peripheral device. It explicitly addresses the need to provide a user with different ways to interact with and view the status of various functions (scanning, printing, etc.) from a single, consistent interface. This establishes the principle of offering multiple, user-selectable views or "perspectives" for a given set of tasks. The '590 patent's examples of different perspectives (e.g., a book view vs. a filmstrip view, see FIGS. 23A-C) are merely different UI layouts for presenting the same underlying data (a multi-page document).

Motivation to Combine/Modify and Rationale for Obviousness:

The motivation for providing multiple viewing modes for data is rooted in fundamental principles of user-friendly software design. A PHOSITA developing an application for viewing multi-page documents would be motivated to provide layouts that are more intuitive and efficient than a simple one-page-at-a-time view. Offering a "book view" (two pages side-by-side) or a "filmstrip view" (thumbnails of multiple pages) are common and predictable solutions to this design problem.

Dell teaches the broader concept of a unified interface with multiple selectable modes of operation. Applying this concept to an image viewer is a simple extension of this known UI principle. The "invention" of claim 32 is not a novel technical process, but rather a description of a user interface feature. Creating different visual layouts for displaying a list of images was a well-known practice in file managers and image editing software of the era (e.g., thumbnail views, list views, detail views). The idea of providing selectable "perspectives" would have been an obvious design choice to a PHOSITA tasked with creating a competitive and usable image viewing application.

U.S. Patent 6,185,590: Term, Family, and Expiration Analysis

Washington, D.C. - An analysis of U.S. Patent 6,185,590, titled "Process and architecture for use on stand-alone machine and in distributed computer architecture for client server and/or intranet and/or internet operating environments," provides the following details regarding its term, related applications, and legal status.

Application and Term Details:

• Application Number: 08/950,838
• Filing Date: October 15, 1997
• Issue Date: February 6, 2001
• Patent Term: As this patent was filed after June 7, 1995, its term is 20 years from the earliest non-provisional filing date.

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

A review of the USPTO's public records for this patent indicates no Patent Term Adjustments (PTA) or Patent Term Extensions (PTE) were granted. The prosecution history does not show any unusual delays by the USPTO that would warrant a PTA. PTE is typically granted for delays caused by regulatory review (e.g., by the FDA) and is not applicable to this technology.

Continuations and Divisional Applications:

• Continuation-in-Part: The application for this patent (08/950,838) is a continuation-in-part of U.S. patent application Ser. No. 08/911,083, filed on August 14, 1997. This earlier filing date is the one used for calculating the patent term.

Related Family Members:

U.S. Patent 6,185,590 claims priority from several provisional applications filed on October 18, 1996:

• 60/028,129: "COMPUTER PROCESS FOR IMAGE CONTROL"
• 60/028,522: "COMPUTER PROCESS FOR IMAGE CONTROL"
• 60/028,128: "COMPUTER PROCESS FOR ENGINE BENCHMARKING"
• 60/028,697: "COMPUTER PROCESS FOR DESK TOP IMAGING"
• 60/028,639: "COMPUTER PROCESS FOR IMAGE VIEWING"
• 60/028,685: "COMPUTER PROCESS FOR IMAGE CAPTURE"

Furthermore, the patent is part of a larger family of related patents and applications that claim priority back to it, including:

• U.S. Patent 7,986,426 (Application No. 12/328,104)
• U.S. Patent 8,488,173 (Application No. 13/182,857)
• U.S. Patent Application Publication 2013/0208318 (Application No. 13/839,344)
• U.S. Patent Application Publication 2013/0208316 (Application No. 13/838,689)
• U.S. Patent Application Publication 2013/0208317 (Application No. 13/838,916)

These subsequent filings represent efforts to continue and expand upon the technology disclosed in the original '590 patent.

Projected Expiration Date:

The term of a U.S. patent filed after June 7, 1995, is 20 years from the filing date of the earliest U.S. or international (PCT) application to which priority is claimed (excluding provisional applications).

1. Earliest Non-Provisional Filing Date: The application for U.S. Patent 6,185,590 is a continuation-in-part of application Ser. No. 08/911,083, which was filed on August 14, 1997. This is the critical date for calculating the patent term.
2. Calculation: Adding 20 years to the earliest filing date:
   • August 14, 1997 + 20 years = August 14, 2017.

Barring any unrecorded term adjustments or disclaimers, and assuming all required maintenance fees were paid in a timely manner, the patent expired on August 14, 2017. The Google Patents legal status of "Expired - Lifetime" confirms this calculation.

Defensive Disclosure and Prior Art Publication

Title: Methods and Architectures for Abstraction, Distribution, and Interaction with Heterogeneous Software Modules

Publication Date: May 11, 2026

Abstract: This document discloses a series of technical implementations, variations, and applications of a component-based software architecture. The core concept involves abstracting the unique Application Programming Interfaces (APIs) of diverse software modules (termed "engines") into standardized, manageable components. These components are designed to operate in both standalone and distributed computing environments, including client-server, intranet, and internet contexts. The disclosures herein expand upon this concept by introducing alternative components, applications in extreme operational parameters, cross-domain implementations, integration with modern technologies like AI, IoT, and blockchain, and fail-safe operational modes. The intent is to place these derivative concepts into the public domain to serve as prior art for future patent applications in this domain.

---

Derivative Works Based on Core Architecture (Ref: Claims 1, 11, 18)

This section describes variations on the three-layer architecture (Engine Management, Engine Configuration, Engine Function) for abstracting a native API into a standardized component.

1. Material & Component Substitution

1.1. WebAssembly (WASM) as the Engine Container

• Enabling Description: Instead of relying on platform-specific Dynamic-Link Libraries (DLLs), the core technology "engine" is compiled to a WebAssembly (WASM) module. The Engine Management Layer (Layer 1) is implemented as a WASM runtime host (e.g., Wasmer or Wasmtime) embedded within the component. The LoadLibrary() function call is replaced by a wasm_instance_new() call, which instantiates the WASM module in a sandboxed memory space. The Engine Management Layer's function mapping is achieved by introspecting the WASM module's exported functions. This approach provides cross-platform compatibility (Windows, macOS, Linux, web browsers) and enhanced security due to the WASM sandbox, preventing the engine from causing system-level faults. The Engine Configuration Layer (Layer 2) communicates with the WASM instance by writing to or reading from its linear memory, which is pre-configured to represent the engine's settings structure.
• Mermaid Diagram:

  graph TD
      A[Object Manager] --> B{WASM-based Engine Component};
      subgraph B
          C[Engine Functions (WASM Exports)]
          D[Engine Configuration (WASM Linear Memory)]
          E[Engine Management (WASM Runtime)]
      end
      E -- Instantiates --> F[Engine.wasm Module];
      E -- Maps Exports --> C;
      D -- Configures --> F;
      A -- Invokes --> C;
  

1.2. GraphQL as the Standardized Interface Definition

• Enabling Description: The "substantially consistent interface" is formally defined using a GraphQL schema. The Engine Function Layer (Layer 3) is implemented as a GraphQL server that resolves queries and mutations. An ExecuteFunction call is replaced by a GraphQL mutation, e.g., mutation { ocrImage(source: "base64_string") { text, confidence } }. The Engine Configuration Layer (Layer 2) exposes engine settings via GraphQL queries, e.g., query { ocrSettings { language, dpi } }, and allows modification via mutations. This provides a strongly-typed, self-documenting, and network-efficient interface, allowing clients (Object Managers) to request only the specific data they need, reducing bandwidth and processing overhead compared to generic COM or RPC calls.
• Mermaid Diagram:

  sequenceDiagram
      participant Client as Object Manager
      participant Component as Engine Component (GraphQL Server)
      participant Engine as Native "C" API Engine
      Client->>+Component: GraphQL Mutation: ocrImage(...)
      Component->>Component: Parse Query, Resolve ocrImage
      Component->>+Engine: Call native_ocr_function(params)
      Engine-->>-Component: Return OCR Result
      Component->>Component: Format Result as JSON
      Component-->>-Client: JSON Payload { data: { ocrImage: { ... } } }
  

---

2. Operational Parameter Expansion

2.1. Real-Time, Deterministic Engine Management for Avionics

• Enabling Description: The architecture is implemented within a Real-Time Operating System (RTOS) like VxWorks or PikeOS, targeting safety-critical applications (e.g., flight control systems). The Engine Management Layer (Layer 1) is modified to provide deterministic guarantees for engine loading and function invocation. Dynamic memory allocation is replaced with pre-allocated memory pools to avoid non-deterministic heap fragmentation. Function pointers are resolved at system startup rather than on-demand to eliminate lookup latency. The ActivateEngine() function includes a deadline parameter, and if the engine's DLL/shared object cannot be loaded and initialized within the specified microsecond timeframe, a hard real-time fault is triggered. This ensures that a backup or redundant engine can be activated without compromising system stability.
• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Inactive
      Inactive --> Loading: ActivateEngine(deadline)
      Loading --> Active: [Load & Init OK] / Start Timer
      Loading --> Fault: [Deadline Exceeded]
      Active --> Inactive: DeactivateEngine()
      Active --> Executing: InvokeFunction()
      Executing --> Active: [Execution Complete]
      Fault --> [*]
  

2.2. Massive Parallelism for GPU-based Computational Engines

• Enabling Description: The architecture is adapted to manage CUDA or OpenCL "engines" for massively parallel computation. The Engine Component resides on a server with multiple GPUs. The Engine Management Layer (Layer 1) manages GPU contexts and memory, loading and compiling PTX or SPIR-V kernels. The Engine Configuration Layer (Layer 2) allows the Object Manager to specify parameters like grid size, block size, and shared memory allocation. The Engine Function Layer (Layer 3) translates standardized function calls (e.g., ProcessMatrix) into a sequence of cudaMemcpy (Host to Device), kernel launch, and cudaMemcpy (Device to Host) operations. The Object Manager can queue multiple jobs, and the Engine Component manages a command queue for each available GPU, distributing the workload for maximum throughput.
• Mermaid Diagram:

  graph LR
      subgraph Client
          OM(Object Manager)
      end
      subgraph Server
          EC[Engine Component]
          subgraph GPU1
              K1(Kernel A)
              M1(GPU Memory)
          end
          subgraph GPU2
              K2(Kernel B)
              M2(GPU Memory)
          end
      end
      OM -- Request(Data, Kernel_A) --> EC
      OM -- Request(Data, Kernel_B) --> EC
      EC -- Manages Queue --> GPU1
      EC -- Manages Queue --> GPU2
      EC -->|1. cudaMemcpy H->D| M1
      EC -->|2. Launch| K1
      EC -->|3. cudaMemcpy D->H| M1
      EC -->|1. cudaMemcpy H->D| M2
      EC -->|2. Launch| K2
      EC -->|3. cudaMemcpy D->H| M2
  

---

3. Cross-Domain Application

3.1. Aerospace: Modular Flight Management Systems (FMS)

• Enabling Description: In an FMS, different avionics subsystems (e.g., GPS, Inertial Reference System, VOR/DME receivers) are treated as "engines," each with a proprietary data protocol and API. An Engine Component is created for each subsystem. The Engine Management Layer handles the initialization and health checks for the hardware interface (e.g., ARINC 429 bus). The Engine Configuration Layer standardizes settings, such as navigation database selection or sensor calibration offsets. The Engine Function Layer provides a uniform API, like GetCurrentPosition() or GetGroundSpeed(), to the Object Manager (the primary flight computer). This allows for "plug-and-play" replacement of avionics boxes from different manufacturers without rewriting the core FMS logic.
• Mermaid Diagram:

  flowchart TD
      FMC[Flight Management Computer<br/>(Object Manager)]
      
      subgraph GPS Component
          L3_GPS[Standard Func: GetPosition()]
          L2_GPS[Config: SetDatum()]
          L1_GPS[Mgmt: Init_ARINC429()]
      end
  
      subgraph IRS Component
          L3_IRS[Standard Func: GetAttitude()]
          L2_IRS[Config: Align(lat,lon)]
          L1_IRS[Mgmt: HealthCheck()]
      end
  
      GPS[GPS Receiver<br/>(Engine)]
      IRS[Inertial Reference System<br/>(Engine)]
      
      FMC --> L3_GPS
      FMC --> L3_IRS
      L1_GPS --> GPS
      L1_IRS --> IRS
  

3.2. AgTech: Unified Farm Sensor Data Aggregation

• Enabling Description: A farm management platform (the Object Manager) needs to integrate data from disparate IoT sensors: soil moisture probes (Modbus), weather stations (proprietary HTTP API), and drone imagery analysis services (REST API). Each sensor type is an "engine." An Engine Component is deployed for each, typically on an edge gateway device. The Engine Management Layer handles the specific communication protocol (TCP, serial, HTTP). The Engine Configuration Layer normalizes sensor data, converting different units (e.g., Celsius to Fahrenheit) and data formats (e.g., XML to a standard JSON object). The Engine Function Layer provides consistent calls like GetSoilMoisture(field_id) or GetLatestNDVIMap(field_id), which the Object Manager can use to build a unified dashboard for the farmer.
• Mermaid Diagram:

  graph TD
      Dashboard[Farm Dashboard<br/>(Object Manager)]
  
      subgraph EdgeGateway
          subgraph SoilSensor_Component
              L3_Soil[Func: GetMoisture()]
              L2_Soil[Config: SetPollingInterval()]
              L1_Soil[Mgmt: ConnectModbus()]
          end
          subgraph WeatherStation_Component
              L3_Weather[Func: GetTemperature()]
              L2_Weather[Config: SetAPIKey()]
              L1_Weather[Mgmt: EstablishHTTP()]
          end
      end
  
      Soil[Soil Probe (Engine)]
      Weather[Weather Station (Engine)]
      
      Dashboard -- Over Network --> L3_Soil
      Dashboard -- Over Network --> L3_Weather
      L1_Soil --> Soil
      L1_Weather --> Weather
  

3.3. Consumer Electronics: Smart Home Hub Interoperability

• Enabling Description: A universal smart home hub (Object Manager) uses the architecture to control devices from different ecosystems (e.g., Philips Hue, Google Nest, Apple HomeKit). Each device API (Zigbee, Matter, proprietary cloud API) is an "engine." The Engine Component for a Philips Hue bridge, for example, would have its Engine Management Layer handle network discovery and authentication with the bridge. The Engine Configuration Layer would abstract device-specific settings like color temperature ranges or supported effects. The Engine Function Layer provides standardized commands like SetLightState({id: "...", on: true, brightness: 80}), allowing the hub's user interface and automation rules to treat all lights, regardless of manufacturer, in an identical manner.
• Mermaid Diagram:

  classDiagram
  ObjectManager "1" -- "N" EngineComponent
  ObjectManager : +setDeviceState(id, state)
  EngineComponent <|-- HueComponent
  EngineComponent <|-- NestComponent
  EngineComponent : +execute(standardCommand)
  HueComponent : +execute(standardCommand)
  NestComponent : +execute(standardCommand)
  HueComponent ..|> HueBridgeAPI
  NestComponent ..|> NestCloudAPI
  class HueBridgeAPI{
    +setLight(id, payload)
  }
  class NestCloudAPI{
    +setThermostat(id, temp)
  }
  

---

4. Integration with Emerging Tech

4.1. AI-Driven Automatic Component Generation

• Enabling Description: The "component factory" concept is fully automated using a large language model (LLM) or a specialized code-generation AI. The factory takes a C-header file (.h), API documentation, and sample code as input. The AI first performs semantic analysis to identify functions, data structures, and their purposes. It then generates the C++ source code for the three-layer Engine Component. The Engine Management Layer code (e.g., loading DLLs, using GetProcAddress) is generated by identifying function signatures. The Engine Configuration Layer is created by mapping API constants and settings structures to a table-driven implementation. The Engine Function Layer maps the high-level standardized calls to the wrapped C functions. The process concludes with automated compilation and testing of the newly generated component against the sample code.
• Mermaid Diagram:

  graph TD
      subgraph AI Component Factory
          A[Input: Header Files, Docs] --> B(Semantic Analysis);
          B --> C{Identify Functions & Settings};
          C --> D[Generate Engine Management Layer];
          C --> E[Generate Engine Config Layer];
          C --> F[Generate Engine Function Layer];
          G[Combine & Compile] --> H(Output: Engine Component DLL);
      end
      D -- uses --> Win32_API;
      F -- maps to --> Original_Engine_API;
  

4.2. IoT-Based Dynamic Engine Instantiation

• Enabling Description: The distributed architecture is integrated with an IoT platform. The Object Manager runs in the cloud, while Engine Components are deployable to edge devices or other cloud servers. A network of IoT sensors provides real-time data (e.g., temperature, vibration, location). The Object Manager uses this data to make intelligent decisions about which engines to activate. For example, if a machine's vibration sensor (IoT device) exceeds a threshold, the Object Manager automatically instantiates a "Vibration Analysis Engine Component" on a nearby edge server, passes it the sensor data stream, and triggers an alert if the analysis predicts a failure. The engine is then unloaded when the sensor data returns to normal, conserving resources.
• Mermaid Diagram:

  sequenceDiagram
      participant IoT_Sensor
      participant ObjectManager
      participant Server
      participant EngineComponent
      
      IoT_Sensor->>ObjectManager: Telemetry (Vibration=High)
      ObjectManager->>ObjectManager: Rule Triggered: Analyze Vibration
      ObjectManager->>Server: InstantiateEngine("VibrationAnalyzer")
      Server->>EngineComponent: new()
      EngineComponent-->>Server: Ready
      Server-->>ObjectManager: Handle to Component
      ObjectManager->>EngineComponent: ProcessStream(Telemetry)
      EngineComponent-->>ObjectManager: Result (Predicted Failure)
      ObjectManager->>Server: DeactivateEngine("VibrationAnalyzer")
  

4.3. Blockchain for Auditable Engine Usage (SaaS Metering)

• Enabling Description: The architecture is used to provide Software-as-a-Service (SaaS) access to high-value proprietary engines. Every call from an Object Manager to a remote Engine Component's Function Layer is recorded as a transaction on a private blockchain (e.g., Hyperledger Fabric). The transaction record includes a hash of the input data, the function called, the engine version, a timestamp, and the client's identity. This creates an immutable, tamper-proof audit trail of engine usage. The Engine Configuration Layer reads smart contracts to determine if a client has sufficient payment/credits to execute a function. This provides a transparent and verifiable system for pay-per-use billing and for proving compliance in regulated industries where data processing steps must be logged.
• Mermaid Diagram:

  flowchart LR
      Client[Client App<br/>(Object Manager)] -- 1. API Call --> Server
      subgraph Server
          EC[Engine Component] --> EM[Engine Module]
          EC -- 2. Create Transaction --> BC(Blockchain Ledger)
          BC -- 3. Validate & Record --> BC
      end
      Client <-- 4. Result -- Server
      Auditor -->|Query| BC
  

---

5. The "Inverse" or Failure Mode

5.1. Graceful Degradation with a "Proxy Engine"

• Enabling Description: The distributed system is designed for high availability in unreliable networks. When a client's Object Manager attempts to call a function on a remote Engine Component and the network connection fails, the DCOM/RPC call times out. Instead of returning an error, the Object Manager's wrapper for that engine transparently re-routes the call to a local, lightweight "proxy engine." This proxy provides limited functionality. For example, a full-featured remote OCR engine might be replaced by a local Tesseract-based proxy that is less accurate but provides an immediate, albeit lower-quality, result. The user interface can indicate that the system is in a "degraded" mode. When the network is restored, the Object Manager automatically flushes any queued requests to the primary remote engine.
• Mermaid Diagram:

  stateDiagram-v2
      state "Connected" as S1
      state "Degraded" as S2
      
      [*] --> S1
      S1: Calls go to Remote Engine
      S2: Calls go to Local Proxy Engine
      
      S1 --> S2: Network Failure
      S2 --> S1: Network Restored
  

5.2. "Read-Only" Configuration Mode

• Enabling Description: The Engine Configuration Layer (Layer 2) implements a security model with a "read-only" mode. In this mode, get_setting calls function normally, but any attempt to call a set_setting function is rejected with a "Permission Denied" error. This is useful for creating user roles. An "Administrator" user's Object Manager can operate in read/write mode to configure engines, while a "Standard User" can only view the current settings but not change them. The mode is established by the Object Manager during the initial connection to the Engine Component, passing a security token that the Engine Management Layer validates to set the internal state of the configuration layer.
• Mermaid Diagram:

  sequenceDiagram
      actor User
      User->>ObjectManager: Login(credentials)
      ObjectManager->>AuthService: Authenticate(credentials)
      AuthService-->>ObjectManager: Return Token (Role: 'ReadOnly')
      ObjectManager->>EngineComponent: Connect(Token)
      EngineComponent->>EngineComponent: Set Internal State to ReadOnly
      User->>ObjectManager: Attempt setSetting("dpi", 300)
      ObjectManager->>EngineComponent: setSetting("dpi", 300)
      EngineComponent-->>ObjectManager: Error: Permission Denied
  

---

Combination Prior Art Scenarios with Open-Source Standards

1. Engine-as-a-Filesystem with FUSE: The core architecture is combined with the Filesystem in Userspace (FUSE) library. The Object Manager is implemented as a FUSE daemon that mounts a virtual filesystem, e.g., /mnt/engines. Each available Engine Component appears as a subdirectory, e.g., /mnt/engines/ocr_engine. The engine's settings are exposed as simple text files within that directory (e.g., cat /mnt/engines/ocr_engine/language returns "en-US"). Changing a setting is done via echo "de-DE" > /mnt/engines/ocr_engine/language. Engine functions are exposed as special "action" files. Writing the path to an input file into an action file triggers the function, and the output is written to a corresponding results file. For example: echo "/path/to/image.tif" > /mnt/engines/ocr_engine/recognize_text. The system then creates /mnt/engines/ocr_engine/recognize_text.result containing the OCR'd text. This makes every engine on the system accessible and scriptable from any standard command-line shell or programming language with basic file I/O capabilities.

2. Distributed Processing Pipeline with Apache Kafka: The distributed architecture is integrated with Apache Kafka to create a scalable, asynchronous processing pipeline. An "ingest" process drops image files into a network storage location and publishes a message to a Kafka topic named images-for-processing. Multiple consumer services are deployed, each containing an Engine Component (e.g., OCR, barcode, image-cleanup). These services subscribe to the images-for-processing topic. When a message is received, the Engine Component processes the corresponding image file and publishes its results (e.g., a JSON object with the extracted text) to a different topic, such as ocr-results. The Object Manager becomes a monitoring and control dashboard, using Kafka's APIs to view consumer lag, manage the deployment of new engine consumers, and re-route data flows, providing a resilient and decoupled system for high-volume document processing.

3. Standardized Web Services via OpenAPI/Swagger: The "consistent interface" of the engine components is formally defined using the OpenAPI 3.0 specification. Each Engine Component is wrapped in a microservice with a RESTful API that conforms to this specification. The Engine Management Layer handles service startup and shutdown. The Engine Configuration Layer is exposed through GET and PUT requests to endpoints like /config. The Engine Function Layer is exposed via POST requests to endpoints like /actions/recognize. The Object Manager is then no longer a monolithic component but can be auto-generated from the OpenAPI schema in any language (Python, Java, JavaScript, etc.) using tools like Swagger Codegen. This makes the entire ecosystem of engines instantly accessible as standard web services, discoverable, and usable by any modern web or enterprise application without needing proprietary client libraries.