Obviousness — US Patent 6044382

An analysis of the obviousness of U.S. Patent 6,044,382 under 35 U.S.C. § 103 requires identifying prior art references that, when combined, would have made the invention obvious to a person having ordinary skill in the art (POSITA) at the time the invention was made. The priority date of the patent is May 19, 1995.

A POSITA at that time would have possessed a bachelor's degree in computer science or a related field, along with several years of experience in client-server architecture, network programming, and transaction-based systems. They would have been familiar with the industry's move toward network-centric computing and the desire for "thin-client" architectures to simplify software deployment and reduce costs on the user's end.

The analysis below is based on the prior art references cited by the USPTO examiner during the prosecution of the '382 patent.

Ground 1: Claims 1 and 13 are obvious over Reisman (US 5,694,546) in view of Judson (US 5,572,643) and Pitroda (US 5,590,038).

This combination of references teaches a dynamically configurable, OS-independent client device for conducting various commercial transactions, as claimed in the '382 patent.

Summary of Prior Art Teachings:

Reisman (US 5,694,546): Reisman discloses a system for creating and distributing interactive applications. The core of Reisman is a central "authoring system" where applications are defined in a "script." This script is downloaded to a client machine that runs a "player" application. The player interprets the script to generate an interactive session for the user, such as a survey or a form-based application. This is directly analogous to the '382 patent's concept of a server downloading "forms" as "data streams" to a Transaction Assembly Server (TAS) on a host computer. Reisman’s "player" is the functional equivalent of the TAS, and his "script" is the functional equivalent of the "form as a data stream."
Judson (US 5,572,643): Judson teaches a client-server architecture specifically designed to minimize the processing and software burden on the client, a concept known as a "thin client." In Judson, the application logic resides on the server, which sends user interface components and data to the client as needed. The motivation, as in the '382 patent, is to create inexpensive and easy-to-maintain client terminals that can access a wide variety of applications without requiring local installation.
Pitroda (US 5,590,038): Pitroda describes a "universal personal communicator" for conducting a wide range of electronic transactions, including banking, shopping, and making travel reservations. It teaches a handheld device that connects to various service provider systems to perform these functions. Pitroda establishes the market context and demand for a single device capable of handling multiple types of transactions, which is a key application environment described in the '382 patent.

Motivation to Combine and Rationale for Obviousness:

A POSITA in 1995 would have found it obvious to combine these teachings. Judson provides the compelling business and technical motivation—reducing client-side complexity and cost—for implementing a thin-client architecture. A POSITA seeking to build such a system would naturally look for an enabling technology to deliver application interfaces from the server to the client.

Reisman provides precisely such a technology. A POSITA would have recognized that Reisman's script-and-player model is an elegant way to realize the thin-client vision of Judson. Instead of just sending static UI components, Reisman’s scripts could define the entire interactive form-based experience. The motivation to combine Judson and Reisman would be to use Reisman's downloadable, interpretable scripts to implement Judson's vision of a server-driven, thin-client application architecture.

With this combined Reisman/Judson architecture in mind, a POSITA would then consider what applications to deploy. Pitroda clearly outlines the most commercially relevant applications for such a device: universal access to banking, retail, and travel services. It would have been obvious to apply the Reisman/Judson architecture to build the universal transaction device described by Pitroda.

This combination teaches every element of independent claims 1 and 13:

A client-server connection is established (Judson, Reisman, Pitroda).
A "form for a particular application" is downloaded "as a data stream" (this is Reisman's "script").
The form is stored and used by a processor to "reconfigure said host computer" (this is what Reisman's "player" does by interpreting the script, turning a general-purpose player into a special-purpose application interface).
The user interacts with the form to create a "data transaction" which is sent back to the server (the explicit purpose of the systems in Reisman and Pitroda).
The resulting system is "operating system independent" in the sense that the applications are defined by the downloaded forms/scripts, not by software compiled for a specific local OS (a direct result of the architecture taught by Reisman and Judson).

Ground 2: Claim 22 is obvious over Reisman (US 5,694,546) in view of Lawlor et al. (US 5,220,501).

This combination focuses on the server-side functionality claimed in the '382 patent, particularly the "exploding" of a data transaction.

Summary of Prior Art Teachings:

Reisman (US 5,694,546): As established above, Reisman teaches the server-side components for an interactive, form-based system. This includes a memory for storing the application "scripts" (the claimed "forms") and a communication interface (the claimed "modem") for downloading the scripts and receiving user data in return.
Lawlor et al. (US 5,220,501): Lawlor describes a system for remote transaction processing, specifically for financial services like stock trading. A central host computer receives transaction requests from portable terminals. Crucially, a single transaction request from a user (e.g., "buy 100 shares of XYZ") necessitates multiple updates on the server side. The server must update the user's account, the firm's inventory, settlement records, and trade logs. This inherent function of processing a single user request by updating multiple distinct files or database records is functionally identical to the '382 patent's concept of "exploding" a data transaction into a "plurality of component data transactions."

Motivation to Combine and Rationale for Obviousness:

A POSITA building the server described by Reisman would need to implement the back-end processing for the data received from the user. Reisman's server receives the user's answers, but Reisman does not detail how this data is processed to update business records. Lawlor provides a clear example of how to handle such incoming requests in a transactional environment.

A POSITA would have been motivated to combine the teachings to create a complete, end-to-end system. The Reisman server would be used for the front-end user interaction (delivering forms and collecting data), and the back-end processing logic described by Lawlor would be implemented on that same server to handle the incoming data. This is not a patentable leap, but a routine integration of a known front-end with a known back-end. A single transaction from a user filling out a Reisman script (e.g., a purchase order) would obviously need to update multiple databases on the server (inventory, accounts receivable, shipping), as taught by the principles in Lawlor.

This combination teaches every element of independent claim 22:

A server system with a memory for storing forms ("scripts" in Reisman) and a modem for communication (Reisman).
A controller that receives the completed data transaction from the host computer (Reisman).
The controller processes the received transaction and "explodes" it into component transactions to be stored in a database (the necessary back-end processing for any real-world transaction system, as exemplified by Lawlor).