Obviousness — US Patent 6185590

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:

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.
Configuration Layer: Corresponds to the common practice of setting parameters or options before executing a function.
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.