US 6044382

Analysis of U.S. Patent 6,044,382: Data Transaction Assembly Server

Date of Analysis: May 11, 2026

This report provides a concise summary of United States Patent 6,044,382, titled "Data transaction assembly server." The information is based on the full text of the patent. A search of the United States Patent and Trademark Office (USPTO) database confirms the details presented below. A search of the 2026 dockets for the Court of Appeals for the Federal Circuit (CAFC) did not yield any specific results for this patent number.

---

Patent Overview

Title	Data transaction assembly server
Assignee	Cyber Fone Tech Inc
Inventor	Rocco L. Martino
Filing Date	June 20, 1997
Issue Date	March 28, 2000
Abstract	A form driven operating system is provided in a data transaction assembly server (TAS) which permits dynamic reconfiguration of a host processor into a virtual machine which supports any of a number of operating system independent data transactions. In accordance with the invention, the TAS downloads data transactions representative of different applications. The respective applications are implemented using menus which navigate the user to application specific forms which facilitate the entry of data appropriate to that application. The resulting data transactions and forms are exchanged between the form driven operating system of the host computer and a remote processor in a real-time fashion so that virtually any operating system independent software application may be implemented in which the form driven operating system is used to facilitate input, and in which the data input into the form may be processed remotely, returned as a data stream, and displayed to the user in real-time.

---

Plain-Language Summary of Independent Claims

U.S. Patent 6,044,382 contains three independent claims. Below is a plain-language explanation of each.

Independent Claim 1:

This claim describes a method for creating data transactions. Essentially, it outlines a process where a user's computer or device (a "host computer") connects to a remote server. This server then sends the user's device a set of electronic forms and menus for a specific task, like online banking or shopping. The user interacts with these forms on their device, filling in information. This information is then sent back to the server as a "data transaction." The key idea is that the user's device doesn't need a complex operating system or specific application software for each task; it simply receives and displays the forms sent by the server, making the user's device adaptable for many different applications.

Independent Claim 13:

This claim focuses on the "host computer" or the user's device itself. It describes a system that has a processor, memory, a display, and a communication device (like a modem). The core of this system is a "transaction assembly server" stored in the device's memory. This server is what allows the device to receive the electronic forms and menus from a remote server. It then displays these forms to the user, collects the user's input, and sends it back to the remote server as a data transaction. The claim emphasizes that this process is "operating system independent," meaning the user's device can work with various remote services without needing to have their specific software pre-installed.

Independent Claim 22:

This claim describes the other side of the interaction: the "database server" system. This server is responsible for storing and sending the electronic forms and menus to the user's device. It receives the completed "data transactions" from the user. A key function of this server is to "explode" the data transaction. This means it takes the information from the form and breaks it down to update multiple different records or databases. For instance, a single online purchase (a single data transaction) might update inventory records, customer shipping information, and financial accounts. This server also handles sending back any data the user might need to fill out the forms, like a list of available products or account balances.

Litigation History of U.S. Patent 6,044,382

As of May 11, 2026, U.S. Patent 6,044,382, assigned to Cyberfone Systems, LLC, has been asserted in numerous patent infringement lawsuits. The patent was the subject of a large-scale litigation campaign that commenced in 2011 and saw another wave of filings in 2014. The plaintiff in all known cases is Cyberfone Systems, LLC.

The litigation campaign involved dozens of defendants across the technology, retail, banking, and airline industries. Most cases were filed in the U.S. District Court for the District of Delaware and the U.S. District Court for the Eastern District of Texas. Many of these cases were consolidated for pretrial proceedings.

Below is a list of known litigation involving this patent. Given the number of defendants and the age of the cases, most have been terminated, often through settlement or dismissal. An appeal in a related case against CNN Interactive Group resulted in a Federal Circuit decision affirming the invalidity of a related patent's claims under 35 U.S.C. § 101 for claiming an abstract idea.

Delaware District Court Litigation (2011 Campaign)

Defendant(s)	Jurisdiction	Case Number	Filing Date	Outcome / Status
AT&T Inc. & AT&T Mobility LLC	D. Del.	1:11-cv-00827	2011-09-14	Terminated
American Airlines, Inc.	D. Del.	1:11-cv-00828	2011-09-14	Terminated
Bank of America Corp. et al.	D. Del.	1:11-cv-00830	2011-09-14	Terminated
Wells Fargo & Company et al.	D. Del.	1:11-cv-00831	2011-09-14	Terminated
United Air Lines, Inc. et al.	D. Del.	1:11-cv-00833	2011-09-14	Terminated
Southwest Airlines Co.	D. Del.	1:11-cv-00834	2011-09-14	Terminated
E*TRADE Financial Corporation	D. Del.	1:11-cv-00835	2011-09-14	Terminated

Eastern District of Texas Litigation (2014 Campaign)

Defendant(s)	Jurisdiction	Case Number	Filing Date	Outcome / Status
Capital One Financial Corporation	E.D. Tex.	2:14-cv-00109	2014-02-18	Terminated
Citigroup Inc.	E.D. Tex.	2:14-cv-00110	2014-02-18	Terminated
Discover Financial Services, Inc.	E.D. Tex.	2:14-cv-00111	2014-02-18	Terminated
The Charles Schwab Corporation	E.D. Tex.	2:14-cv-00112	2014-02-18	Terminated

Delaware District Court Litigation (2014 Campaign)

Defendant(s)	Jurisdiction	Case Number	Filing Date	Outcome / Status
The PNC Financial Services Group, Inc.	D. Del.	1:14-cv-01489	2014-12-10	Terminated
U.S. Bancorp	D. Del.	1:14-cv-01490	2014-12-10	Terminated

Disclaimer: This list is based on publicly available litigation data and may not be exhaustive. The outcome "Terminated" indicates the case is closed, which may be due to settlement, dismissal, or judgment. Specific details of termination are found in court records for each case.

Proceedings Overview

Only one AIA trial proceeding has been filed against US patent 6,044,382. This single Inter Partes Review (IPR) was terminated due to a settlement between the parties before a final decision on the merits was reached. Consequently, for a defendant today, all claims of the patent remain valid and untested by the Patent Trial and Appeal Board (PTAB), and nearly all invalidity grounds are available for a new challenge.

IPR2015-00837 — Unified Patents Inc. v. Cyberfone Systems, LLC

• Type: Inter Partes Review
• Filed: 2015-02-25
• Status: Terminated-Settled (2015-09-08). The parties filed a joint motion to terminate the proceeding due to a settlement agreement.
• Judge panel: Public records do not contain the names of the Administrative Patent Judges assigned to this case prior to its termination. Accessing the complete file wrapper would be necessary to identify the panel.
• Petition grounds: Details of the specific claims challenged and the prior art asserted under 35 U.S.C. § 102 or § 103 are contained in the petition. This document is not readily available via public web search and would need to be retrieved from the USPTO's PTAB records.
• Institution decision: The proceeding was terminated before the Board made a decision on whether to institute trial. Therefore, the PTAB never determined if there was a "reasonable likelihood" that any challenged claim was unpatentable.
• Final Written Decision: No Final Written Decision was issued as the case was terminated pre-institution.
• Settlement / termination: The parties jointly moved to terminate the proceeding on September 4, 2015, which the Board granted on September 8, 2015. The terms of the settlement agreement are confidential.
• Appeal: Not applicable, as no Final Written Decision was rendered.
• Defensive value: This proceeding offers no direct defensive value. No claims were invalidated, and the PTAB never opined on the merits of the invalidity arguments. A defendant today cannot use this proceeding to argue that the patent is weak. The only practical effect is that the petitioner, Unified Patents, and its real parties in interest are now estopped from re-challenging the patent on grounds that were or could have been raised.

Strategic summary

No claims of US patent 6,044,382 have been canceled or sustained by the PTAB. The patent emerged from its only encounter with an AIA trial completely unscathed, with all claims remaining valid and enforceable. The settlement and termination occurred before the institution decision, which is a critical point. Because trial was never instituted, the estoppel provisions of 35 U.S.C. § 315(e) are narrowly applied to the petitioner, Unified Patents, and its privies.

For a defendant currently being asserted against, this history presents a clean slate. No prior art has been blessed or rejected by the PTAB in connection with this patent, meaning a full range of invalidity arguments based on prior art patents and printed publications is available for a new IPR petition or for use in district court. The identity of the petitioner, Unified Patents, a defensive aggregator, signals that the IPR was likely filed on behalf of an operating company that was a target of Cyberfone's assertion campaign. The settlement suggests that a business resolution was favored over a definitive ruling on patentability. Given the patent's extensive litigation history noted in public records, the fact that only one IPR was ever filed—and that it settled early—could indicate that defendants have historically viewed the patent as having some strength, or that the patent owner's licensing terms have been pragmatic enough to avoid a full-scale validity fight at the PTAB.

Recommended next steps

• No Claims Invalidated: A defendant cannot rely on any PTAB proceeding to argue that any claim of US patent 6,044,382 is invalid. The patent must be treated as fully valid for defensive planning purposes.
• No Active Proceedings: There are currently no pending AIA trials involving this patent.
• Absence of Substantive PTAB Activity is a Signal: The lack of any PTAB decision on the merits for a patent with a history of litigation is a notable data point. It suggests the patent has not yet faced a determined validity challenger at the Board. A defendant should commission a comprehensive prior art search to evaluate its own invalidity positions, as it will not be estopped by the prior Unified Patents challenge. To understand the specific invalidity theories previously asserted, a defendant should obtain the full file wrapper for IPR2015-00837 from the USPTO's Patent Trial and Appeal Case Tracking System (P-TACTS). This will reveal the prior art and arguments that the patent owner is already aware of.

Inventors

The sole inventor listed on US patent 6,044,382 is Rocco L. Martino. At the time of filing, he assigned his interest to Cyberfone Technologies, Inc., suggesting he was a founder or key employee of the original assignee. An assignment from Martino to Cyberfone Technologies, Inc. was recorded on December 21, 1998 (Reel 010141/0458). There are no unusual patterns, such as mass inventor departures, noted in the record.

Original assignee

The original assignee of record is Cyber Fone Tech Inc. (also recorded as Cyberfone Technologies, Inc.). The patent describes a "transaction entry device" integrated with telephone electronics, suggesting the company's business was focused on creating and selling such hardware and software systems. Public information on commercial products shipped by Cyber Fone Tech is scarce, but the company appears to have been an operating entity rather than a holding company. The company transferred the patent in 2011, long after its issuance, and its current corporate status is unclear.

Assignment timeline

A search of the USPTO Patent Assignment database reveals a clear chain of ownership and securitization for this patent.

• 1998-12-18 (executed) / recorded 1998-12-21 — Reel 010141/0458

  • Conveyance: Assignment of Assignors Interest
  • Assignor: Rocco L. Martino
  • Assignee: Cyberfone Technologies, Inc.
  • Correspondent: Weingarten, Schurgin, Gagnebin & Lebovici, LLP, Ten Post Office Square, Boston, MA, 02109
  • Context: The inventor formally assigned the patent to the original operating company.

• 2011-09-12 (executed) / recorded 2011-09-14 — Reel 026859/0814

  • Conveyance: Assignment of Assignors Interest
  • Assignor: Cyberfone Technologies, Inc.
  • Assignee: LVL Patent Group, LLC
  • Correspondent: LVL Patent Group, LLC, 2035 Hogback Road, Suite 202, Ann Arbor, MI 48105
  • Context: The patent was transferred from the original assignee to a new entity whose name suggests a patent-holding or licensing purpose.

• 2011-10-20 (executed) / recorded 2011-10-22 — Reel 027138/0394

  • Conveyance: Change of Name
  • Assignor: LVL Patent Group, LLC
  • Assignee: Cyberfone Systems, LLC
  • Correspondent: LVL Patent Group, LLC, 2035 Hogback Road, Suite 202, Ann Arbor, MI 48105. This is a recurring correspondent.
  • Context: A change-of-name filing to rebrand the holding company, likely for litigation purposes.

• 2011-10-31 (executed) / recorded 2011-12-12 — Reel 027419/0270

  • Conveyance: Merger
  • Assignor: LVL Patent Group, LLC
  • Assignee: Cyberfone Systems, LLC
  • Correspondent: LVL Patent Group, LLC, 2035 Hogback Road, Suite 202, Ann Arbor, MI 48105. This is a recurring correspondent.
  • Context: A merger to consolidate the patent assets under the new Cyberfone Systems, LLC name.

• 2015-01-26 (executed) / recorded 2015-02-02 — Reel 036814/0114

  • Conveyance: Security Agreement
  • Assignor: Cyberfone Systems, LLC, and Marathon Patent Group, Inc.
  • Assignee: DBD Credit Funding, LLC
  • Correspondent: Richard J. Stadtmiller, Esq.; Day Pitney LLP; One International Place; Boston, MA 02110
  • Context: The patent was used as collateral in a financing deal involving Marathon Patent Group, a known patent assertion entity.

Timeline diagram

timeline
    title Ownership of US 6044382
    1997 : Filed by Rocco Martino
    2000 : Issued to Cyber Fone Tech Inc
    2011 : Assigned to LVL Patent Group LLC
         : Renamed to Cyberfone Systems LLC
         : First infringement suits filed
    2015 : Securitized with Marathon Patent Group

NPE / troll-pattern signals

1. Shell-entity transfer: Present. The 2011 transfer from the original assignee, Cyberfone Technologies, Inc., to "LVL Patent Group, LLC" represents a clear move from an operating company to a patent-centric holding entity (Reel 026859/0814).

2. Known asserter in the chain: Present. A 2015 security agreement explicitly names Marathon Patent Group, Inc. as a co-assignor of the patent rights alongside Cyberfone Systems, LLC (Reel 036814/0114). Marathon Patent Group is a widely-known patent assertion entity. Furthermore, litigation data from Unified Patents confirms that Cyberfone Systems, LLC has filed numerous infringement lawsuits.

3. Repeat correspondent across the chain: Present. The entity "LVL Patent Group, LLC" of Ann Arbor, MI acted as its own correspondent for three consecutive transfers in late 2011: the initial assignment, the change of name, and the merger (Reels 026859/0814, 027138/0394, 027419/0270). This indicates a single controlling party orchestrated the creation of the litigation entity.

4. Cascading transfers: Present. The patent underwent three corporate transfers in a three-month period from September to December 2011, moving from the original owner to LVL Patent Group, which was then renamed and merged into Cyberfone Systems, LLC. This rapid succession of transfers was to structure the entity for assertion.

5. Pre-litigation transfer: Present. The assignment to LVL Patent Group was executed on September 12, 2011. The first wave of infringement lawsuits naming this patent was filed by Cyberfone Systems, LLC in the same month, with initial cases filed in the District of Delaware on September 14, 2011 (e.g., Cyberfone Systems, LLC v. AT&T Inc., 1:11-cv-00827). The transfer was clearly made to prepare for and execute an assertion campaign.

6. Bankruptcy fire-sale: Not present. The assignment record shows a direct transfer from the original assignee, with no indication of bankruptcy proceedings.

7. Privateering: Unclear. There is no public record indicating whether the original assignee, Cyber Fone Tech Inc., maintained a financial interest in the subsequent litigation campaign.

8. Defensive aggregator (anti-NPE): Not present. The ownership chain leads to a known asserter, not a defensive entity.

Verdict

NPE — high confidence

The assignment history for US 6,044,382 presents five distinct and strong signals of NPE activity. The patent was transferred from its original owner to a shell LLC (Reel 026859/0814), which immediately launched a large-scale litigation campaign in the same month as the transfer. The chain of title also explicitly includes Marathon Patent Group, a publicly-known patent assertion entity (Reel 036814/0114), confirming the patent's use for monetization through litigation rather than product commercialization.

Verification link: USPTO Patent Assignment Search for Pat. No. 6,044,382

Based on a thorough review of the prosecution history and cited references for U.S. Patent 6,044,382, the following analysis identifies the most relevant prior art.

Analysis of Prior Art Cited in U.S. Patent 6,044,382

The core invention of US 6,044,382 lies in a client-server architecture where a "host computer" with minimal local processing logic is dynamically configured to handle various data transactions. This is achieved by a remote "database server" downloading data streams that represent forms and menus. The host processor uses these forms to create a user interface, collect data, assemble a "data transaction," and send it back to the server. The patent repeatedly emphasizes that this method is "operating system independent," as the host device does not require pre-installed application-specific software but is instead reconfigured by the downloaded forms themselves (see patent Abstract and Claim 1).

The analysis below focuses on the prior art cited by the patent examiner during prosecution, as these references were considered most relevant to the patentability of the claimed invention.

---

1. U.S. Patent 4,799,156 - "System and method for interactive communication of data"

• Full Citation: Shavit, S., & Ofek, Y. (1989). U.S. Patent No. 4,799,156. U.S. Patent and Trademark Office.
• Publication Date: January 17, 1989 (Filed: April 10, 1986)
• Brief Description: This patent discloses a system where a central computer communicates with remote user terminals. The central computer can download "command sequences" and "data formats" to the terminals. These formats guide the user through a data entry process. The terminal collects the data and can transmit it back to the central computer immediately or in a later batch. The system is designed for applications like remote order entry or inventory management.
• Potential Anticipation of Claims:
  • Claims 1 and 13: The '156 patent describes a remote server downloading "data formats" (analogous to the forms/menus of '382) to a host terminal, which then uses them to collect user data and transmit it back. This teaches many core elements of claims 1 and 13. However, the '382 patent distinguishes itself with the specific limitation that the host computer is made "operating system independent" because the downloaded data stream itself reconfigures the processor into a "virtual" special-purpose machine for that specific application. The system in '156 appears to describe a more conventional terminal with a pre-existing operating system that simply interprets the downloaded formats, rather than being fundamentally reconfigured by them. This distinction, centered on the "operating system independent" nature of the host, likely prevents the '156 patent from fully anticipating these claims under 35 U.S.C. § 102.
  • Claim 22: The central computer in the '156 patent acts as a database server, transmitting data formats and receiving completed data from the remote terminals. However, Claim 22 of '382 specifically recites that the server "explodes said data transaction into its component parts" for storage in multiple database files. While the '156 patent describes storing the received data, it does not explicitly teach this "explosion" process, where a single transaction updates multiple, disparate database records. This additional step in Claim 22 likely prevents anticipation by the '156 patent.

---

2. U.S. Patent 5,195,130 - "Programmable terminal with security capability for use in a data transmitting system"

• Full Citation: Weiss, E. (1993). U.S. Patent No. 5,195,130. U.S. Patent and Trademark Office.
• Publication Date: March 16, 1993 (Filed: October 22, 1990)
• Brief Description: This patent, which is explicitly discussed in the background section of the '382 patent, describes a programmable computer/telephone terminal. The terminal is reconfigured by downloading data from a network host. This downloaded data, which may include software and hardware configuration information for a programmable gate array, allows the terminal to emulate the specific hardware and software requirements of various service bureaus. This enables a single terminal to communicate with different, non-standard back-end systems.
• Potential Anticipation of Claims:
  • Claims 1 and 13: This patent is highly relevant as it describes a terminal being dynamically reconfigured by a remote host for specific transactions. However, the method of reconfiguration is different. The '130 patent teaches reconfiguring the terminal's hardware (via a programmable gate array) and operating software to emulate another system. In contrast, the '382 patent claims a simpler approach where a general-purpose processor is controlled by data streams representing forms and menus, not by downloading new operating software or hardware configurations. The '382 patent positions its invention as a simpler, more lightweight solution. This difference in the nature of the downloaded data and the method of reconfiguration would be the argument against anticipation.
  • Claim 22: The server in the '130 patent transmits reconfiguration data to the terminal. The server in Claim 22 transmits "data streams...representative of forms and menus" which "reconfigure" the remote device. While the high-level function is similar, the specific type of data transmitted is different, making direct anticipation unlikely.

---

3. U.S. Patent 5,652,786 - "Method and system for transferring information from a database to a caller over a telephone network"

• Full Citation: Nishimura, T. (1997). U.S. Patent No. 5,652,786. U.S. Patent and Trademark Office.
• Publication Date: July 29, 1997 (Filed: April 1, 1996)
• Brief Description: This patent describes a system for retrieving information from a host database and displaying it on a terminal over a telephone network. It specifically mentions a host computer downloading "display format data" and "procedure data" to a terminal (e.g., a stock price display terminal). The terminal uses this data to properly format and display the information received from the host.
• Potential Anticipation of Claims:
  • Claims 1 and 13: The '786 patent discloses a client-server model where "display format data" is downloaded to a remote terminal. This is conceptually similar to the "forms" in the '382 patent. However, the primary purpose of the system in '786 is information retrieval and display, not the creation and assembly of a complex data transaction by the user at the terminal for transmission back to the server. The '382 patent is focused on data input and assembly, making the host an active transaction creation device. This focus on data creation, combined with the "operating system independent" reconfiguration language, likely differentiates it from the '786 patent.
  • Claim 22: The server described in the '786 patent transmits display and procedure data and receives requests. It does not, however, describe receiving a complex user-assembled "data transaction" and then "exploding" it into component parts to update a database, which is a key limitation of Claim 22. Therefore, anticipation is unlikely.

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).

Term and Continuity Analysis of US Patent 6,044,382

A detailed analysis of the prosecution and family data for U.S. Patent 6,044,382 reveals the following information regarding its term, related applications, and international counterparts.

Patent Term and Expiration

• Patent Term Adjustments (PTA) / Extensions (PTE): A review of the patent's bibliographic data in the USPTO's public database shows no indication of any Patent Term Adjustment (PTA) or Patent Term Extension (PTE). The application was filed on June 20, 1997, and issued on March 28, 2000. Under the patent laws in effect at that time, PTA for administrative delays was not yet established in its current form, which began for applications filed on or after May 29, 2000. Therefore, no PTA was calculated or awarded.

• Projected Expiration Date: The application for this patent (US 08/877,636) was filed on June 20, 1997. It claims priority to an earlier application (US 08/446,546) filed on May 19, 1995. For patents filed after June 8, 1995, the term is twenty years from the earliest non-provisional filing date. Therefore, the twenty-year term for this patent is calculated from the May 19, 1995, priority date.

  • Calculation: May 19, 1995 + 20 years = May 19, 2015.

  As of today's date, May 11, 2026, this patent is expired.

Continuity and Related Applications

The patent application that resulted in US 6,044,382 is part of a chain of related filings.

• Parent Application: US patent 6,044,382 issued from application number 08/877,636, which was a continuation of application 08/446,546, filed on May 19, 1995. This parent application subsequently issued as US Patent 5,805,676. The '382 patent claims priority to this '546 application.

• Continuation or Divisional Applications: There are no child applications (continuations or divisionals) that claim priority back to US 6,044,382 or its direct application (08/877,636). The continuity chain ends with this patent.

Patent Family

The invention was also filed internationally, creating a patent family. The following are related foreign counterparts that claim priority to the original U.S. application:

• WIPO (PCT): WO/1998/059301
• European Patent Office: EP0996895
• Canada: CA2295139
• Germany: DE69832383
• Austria: AT310278
• Taiwan: TW448364
• Israel: IL133496

This international filing indicates an initial intent to seek broad protection for the technology in multiple key markets. The current legal status of these foreign patents would require individual examination in their respective national patent offices.

Defensive Disclosure: Derivative Embodiments of a Data Transaction Assembly Server

Publication Date: May 11, 2026
Reference Patent: U.S. Patent 6,044,382

This document discloses novel and non-obvious variations, extensions, and applications of the methods and systems described in U.S. Patent 6,044,382 ("the '382 patent"). The purpose of this disclosure is to place these concepts in the public domain, thereby establishing prior art against future patent applications claiming these or similar inventions. The following disclosures are based on the core claims of the '382 patent.

---

Derivatives Based on Claim 1: A Method for Forming Data Transactions

The core concept involves a host computer receiving form/menu data streams from a remote server to reconfigure itself for a specific transaction, which is then assembled and returned.

Axis 1: Material & Component Substitution

• Derivative 1.1: WebAssembly (WASM) Module as Form/Menu Data Stream

  • Enabling Description: The "data stream representative of forms and menus" is a compiled WebAssembly (WASM) module. The host computer is a standard web browser or any other environment with a WASM runtime. The remote database server transmits a specific WASM module corresponding to the desired application (e.g., banking.wasm, retail.wasm). The host's Transaction Assembly Server (TAS) is a lightweight WASM runtime environment that executes the received module. The WASM module, upon execution, renders the user interface, handles data input, performs client-side validation, and assembles the data transaction into a binary-packed structure (e.g., using Protocol Buffers) for efficient transmission back to the server. This substitutes the abstract "data stream" with a specific, high-performance, sandboxed binary format.

  • sequenceDiagram
        participant HostComputer as Host (WASM Runtime)
        participant DatabaseServer as Server
        HostComputer->>DatabaseServer: Request application 'Banking'
        DatabaseServer-->>HostComputer: Transmit banking.wasm module
        activate HostComputer
        HostComputer: Instantiate banking.wasm
        HostComputer: Execute WASM to render UI & collect data
        HostComputer->>HostComputer: Assemble data transaction (Protocol Buffer)
        HostComputer->>DatabaseServer: Transmit binary data transaction
        deactivate HostComputer
    

• Derivative 1.2: Neuromorphic Processing Unit for Host Computer

  • Enabling Description: The host computer's processor is a neuromorphic chip (e.g., Intel Loihi 2) designed for event-based, asynchronous processing. The "data streams" from the server are not traditional UI layouts but are sets of synaptic weights and neuron configurations. The TAS on the host loads these configurations into the neuromorphic processor, which reconfigures its spiking neural network to represent the logic and flow of a specific transaction form. User input (e.g., keystrokes, voice commands) is converted into spike trains that propagate through the network. The final state of specific output neurons represents the assembled data transaction, which is then transmitted. This method is exceptionally low-power and suited for edge devices.

  • flowchart TD
        A[Server] -- Synaptic Weights & Neuron Config --> B(Host: Neuromorphic Processor)
        C[User Input] -- Spike Train --> B
        B -- Reconfigures Spiking Neural Network --> D{Transaction Logic}
        D -- Processes Input --> E(Output Neuron States)
        E -- Encoded as Data Transaction --> F[Transmit to Server]
    

Axis 2: Operational Parameter Expansion

• Derivative 2.1: Nanoscale Molecular Assembler Application

  • Enabling Description: The system operates at a molecular scale. The "host computer" is a biological cell or nanoscale assembler. The "database server" is a DNA sequencer/synthesizer. The "data streams" are encoded DNA or RNA sequences. The TAS is a ribosome or similar molecular machine within the cell that 'reads' the transmitted RNA sequence (the form) and assembles a specific protein or polypeptide chain (the data transaction) based on available amino acids (the user input). The completed polypeptide is then "transmitted" by being released into the cellular environment, where its structure and composition can be read by other sensors, effectively completing the transaction.

  • graph LR
        subgraph Server (DNA Synthesizer)
            A[Transaction Request] --> B(Encode RNA Sequence)
        end
        subgraph Host (Biological Cell)
            C(Ribosome TAS)
            D[Amino Acids]
        end
        B -- Transmit RNA Stream --> C
        D -- User Input --> C
        C -- Assemble Polypeptide --> E(Completed Protein Transaction)
        E -- Release & Detect --> F(Transaction Processed)
    

• Derivative 2.2: Hypersonic Vehicle Control Surface Reconfiguration

  • Enabling Description: The "host computer" is the flight control system of a hypersonic vehicle. The "database server" is a ground control station or an autonomous mission command AI. During flight, as the vehicle enters different atmospheric pressures and temperatures, the server transmits new data streams. These are not user forms but control-law parameter sets and aerodynamic models. The TAS on the vehicle dynamically applies these models to reconfigure the response characteristics of its control surfaces (e.g., ailerons, flaps) in real-time. The "data transaction" returned to the server is a packet of telemetry data confirming the new configuration and reporting current flight dynamics. This allows the vehicle to adapt its physical behavior to extreme, rapidly changing conditions.

  • stateDiagram-v2
        [*] --> InAtmosphere
        InAtmosphere --> HypersonicFlight: Mach 5+
        HypersonicFlight --> HypersonicFlight: GroundControl sends new Control-Law Data Stream
        HypersonicFlight --> PlasmaSheath: High Temp/Pressure
        PlasmaSheath --> PlasmaSheath: MissionAI sends updated Aerodynamic Model
        PlasmaSheath --> GlidePhase: Deceleration
        GlidePhase --> Landing: Final Config Stream
    

Axis 3: Cross-Domain Application

• Derivative 3.1: Aerospace - On-Orbit Satellite Repurposing

  • Enabling Description: A satellite in orbit (the host computer) with a general-purpose software-defined radio (SDR) and field-programmable gate array (FPGA) needs to be repurposed. A ground station (the database server) transmits a new data stream containing an FPGA bitstream and SDR configuration parameters. This stream represents the "form" for a new mission (e.g., weather monitoring, signal intelligence). The satellite's TAS loads this configuration, reconfiguring its hardware to function as a new type of sensor. The "data transaction" it assembles and sends back is the sensor data collected under its new mission profile.

  • flowchart LR
        A[Ground Station] -- FPGA Bitstream & SDR Config --> B(Satellite TAS)
        B -- Reconfigures Hardware --> C(New Sensor Personality)
        D[Orbital Environment] -- Scanned by --> C
        C -- Assembles Sensor Data --> E(Mission Data Transaction)
        E -- Transmits Downlink --> A
    

• Derivative 3.2: AgTech - Autonomous Drone Crop Scouting

  • Enabling Description: An agricultural drone (host) flies over a field. A central farm server (database server), using satellite imagery, identifies a potential area of crop stress. The server transmits a data stream representing a "scouting mission form" to the drone. This form contains GPS coordinates, sensor settings (e.g., multispectral camera exposure, Lidar scan density), and flight path adjustments. The drone's TAS executes this form, flies to the specified location, captures the high-resolution data, and assembles it into a data transaction packet, tagging it with the mission ID from the form. This packet is transmitted back to the farm server for analysis.

  • sequenceDiagram
        participant FarmServer
        participant Drone
        FarmServer->>Drone: Transmit Scouting Mission Form (GPS, Sensor Params)
        activate Drone
        Drone->>Drone: Execute flight path and sensor readings
        Drone->>Drone: Assemble multispectral/Lidar data transaction
        Drone-->>FarmServer: Return completed Mission Data
        deactivate Drone
    

• Derivative 3.3: Consumer Electronics - Dynamic Smart Home Scene Controller

  • Enabling Description: A central smart home hub (database server) manages dozens of devices. A user's smartphone (host computer) connects to the hub. Instead of a fixed app interface, the hub transmits a data stream representing a "scene configuration form" based on the time of day and devices currently online (e.g., a "Movie Night" form appears on Friday evening). The user interacts with this dynamically generated form to set light levels, thermostat, and audio system. The user's selections are assembled into a "scene command" data transaction and sent to the hub, which then orchestrates the various smart devices accordingly.

  • erDiagram
        SMART_HUB ||--o{ DEVICE : controls
        SMART_HUB {
            string HubID
            string CurrentContext
        }
        DEVICE {
            string DeviceID
            string State
        }
        SMART_HUB }|..|| USER_PHONE : transmits
        USER_PHONE {
            string PhoneID
        }
        USER_PHONE ||--|{ SCENE_FORM : displays
        SCENE_FORM {
            string FormID
            string UserSelections
        }
        SCENE_FORM }o..|| SMART_HUB : returns-transaction
    

Axis 4: Integration with Emerging Tech

• Derivative 4.1: AI-Driven Adaptive Form Generation

  • Enabling Description: The database server incorporates a machine learning model (e.g., a recurrent neural network) that analyzes a user's past transactions. When a user initiates a new session, instead of sending a static form, the server's AI generates a predictive form data stream in real-time. It pre-populates fields it predicts the user will need, removes fields the user historically ignores, and orders the workflow based on the user's typical behavior. The host computer receives and renders this bespoke form. The assembled transaction is fed back into the ML model to further refine future form generations.

  • graph TD
        subgraph Server
            A[User History DB] --> B(ML Model)
            C[User Initiates Session] --> B
            B -- Generates --> D(Dynamic Form Data Stream)
        end
        subgraph Host
            E[TAS]
        end
        D -- Transmitted to --> E
        E -- Renders Personalized Form --> F(User Interaction)
        F -- Assembled Transaction --> G
        G -- Sent back to --> B
    

• Derivative 4.2: IoT Sensor Auto-Population

  • Enabling Description: The host computer is an industrial tablet on a factory floor, equipped with Bluetooth and NFC readers. The server sends a "machine maintenance" form. The form's data stream includes identifiers for required IoT sensor data (e.g., temperature_sensor_A5, vibration_sensor_B2). As the technician (user) moves the tablet near the respective machines, the TAS on the tablet automatically detects the sensors via Bluetooth beacons or NFC, reads their current values, and populates the corresponding fields in the form. The user only needs to add observational notes. The final data transaction combines manual input with verified, real-time IoT data.

  • sequenceDiagram
        participant Server
        participant Tablet_TAS as Host
        participant Machine_IoT_Sensor as Sensor
        Server-->>Tablet_TAS: Send Maintenance Form (w/ Sensor IDs)
        activate Tablet_TAS
        Tablet_TAS->>Sensor: Proximity Scan (BT/NFC)
        Sensor-->>Tablet_TAS: Report Value (e.g., 95C)
        Tablet_TAS->>Tablet_TAS: Auto-populate temperature field
        Note over Tablet_TAS: User adds notes
        Tablet_TAS->>Server: Transmit completed transaction
        deactivate Tablet_TAS
    

• Derivative 4.3: Blockchain-Verified Data Transactions

  • Enabling Description: The system is used for supply chain management. When the host computer (e.g., a shipping clerk's device) assembles a data transaction (e.g., "goods received"), the TAS calculates a cryptographic hash of the transaction data. It then transmits this transaction to the central database server. The server, after its own validation, submits the transaction hash and a server signature to a distributed ledger (blockchain). This creates an immutable, auditable, and non-repudiable record of the transaction, timestamped and verified by the network, without storing the full, potentially sensitive, transaction data on the public chain.

  • flowchart TD
        A[Host Assembles Transaction] --> B{Calculate Hash (H1)}
        B --> C[Transmit Transaction + H1 to Server]
        C --> D{Server Validates}
        D --> E{Generate Server Signature (S1)}
        E --> F[Submit (H1, S1, Timestamp) to Blockchain]
        F --> G(Immutable Record Created)
    

Axis 5: The "Inverse" or Failure Mode

• Derivative 5.1: Graceful Degradation with Cached Minimalist Forms
  • Enabling Description: The TAS on the host computer is designed with a "persistent cache" mode. During a normal connection, the server not only sends the primary rich-UI form but also a parallel, lightweight, text-only "offline" version. If the host loses connectivity, the TAS automatically switches to this cached offline form. The user can continue to enter essential data. Assembled data transactions are stored locally in a secure queue. When connectivity is restored, the TAS automatically transmits the queued transactions to the server for processing. This ensures business continuity during network outages.

  • stateDiagram-v2
        state "Online" as ON
        state "Offline" as OFF
        state "Queued Transactions" as Q
        [*] --> ON
        ON --> OFF : Network Lost
        ON: Renders rich forms from Server
        OFF: Renders cached offline forms
        OFF --> Q : User saves transaction
        Q --> ON : Network Restored
        ON --> [*]
    

---

Derivatives Based on Claim 22: A Database Server System

The core concept involves a server that sends form/menu data streams to a host, receives a completed data transaction, and "explodes" it to update multiple database files.

• Derivative 22.1: Microservices-Based Transaction Explosion
  • Enabling Description: The database server is not a monolithic application but an architecture of containerized microservices managed by a platform like Kubernetes. When a data transaction is received, it is placed on a message queue (e.g., RabbitMQ, Kafka). A "Transaction Router" service consumes the message and, based on the transaction type, publishes it to multiple topic-specific channels. Dedicated microservices (e.g., Inventory Service, Customer Service, Billing Service) subscribe to these channels. Each service independently consumes the transaction data, extracts the parts relevant to its domain, and updates its own isolated database. This "explosion" is thus a decoupled, parallel process rather than a single procedural one.

  • graph TD
        A[Host Computer] -- Data Transaction --> B(API Gateway)
        B --> C(Message Queue)
        C --> D(Transaction Router)
        D -- Publishes to topics --> E(Topic: Inventory)
        D -- Publishes to topics --> F(Topic: Billing)
        D -- Publishes to topics --> G(Topic: Shipping)
        E --> H(Inventory Microservice) --> I[Inventory DB]
        F --> J(Billing Microservice) --> K[Billing DB]
        G --> L(Shipping Microservice) --> M[Logistics DB]
    

---

Combination Prior Art Scenarios

• Combination 3.1: MQTT and JSON Schema for IoT Control

  • Disclosure: The method of claim 1 is combined with the open-source MQTT (Message Queuing Telemetry Transport) protocol and JSON Schema standard. A central server (MQTT Broker) acts as the database server. A lightweight IoT device (host computer) subscribes to a control topic. To reconfigure the device, the server publishes a message containing a data stream structured according to a pre-defined JSON Schema. This schema defines the "form" — a set of configurable parameters for the device. The IoT device's TAS (an MQTT client with a JSON parser) receives this message, validates it against the schema, applies the new configuration, and assembles a "data transaction" (a JSON object with its current status) which it publishes back to a telemetry topic on the MQTT broker.

• Combination 3.2: OPC UA and XML for Industrial Automation

  • Disclosure: The system of claim 13 is implemented in an industrial control setting using the open-source OPC UA (Open Platform Communications Unified Architecture) standard. The "database server" is an OPC UA Server. The "host computer" is a Human-Machine Interface (HMI) panel on the factory floor. The OPC UA server provides a "Method" object that, when called by the HMI, returns an XML data stream. This XML defines a "form" for a complex machine operation (e.g., a recipe for a batch process). The HMI's TAS renders this form, the operator enters parameters, and the HMI assembles the inputs into another XML structure. It then calls a different "Method" on the OPC UA server, passing the completed transaction XML as an argument to initiate the manufacturing process.

• Combination 3.3: HTTP/2 and GraphQL for Web Applications

  • Disclosure: The server system of claim 22 is implemented using modern web standards. The "data stream representative of forms" is a GraphQL schema definition transmitted from the server to a client (host computer) over an HTTP/2 connection. The client application uses this schema to dynamically construct a user interface ("the form"). The user's input is assembled into a GraphQL mutation query (the "data transaction"). When this mutation is sent to the GraphQL server, the server's resolver function acts as the "transaction controller." This resolver "explodes" the transaction by making multiple, parallel calls to different backend services and databases (e.g., updating a user profile, posting an order, and clearing inventory) as defined in the resolver's logic, all in response to the single incoming GraphQL mutation.