US 6032137

A concise summary of US Patent 6,032,137 is provided below.

Title: Remote image capture with centralized processing and storage

Assignee: The original assignee was CSP Holdings LLC. The patent has since been reassigned, with the current listed assignee being SHORE DEARY LLP.

Inventors: Claudio R. Ballard

Filing Date: May 19, 1998

Issue Date: February 29, 2000

Abstract:
A system for remote data acquisition and centralized processing and storage is disclosed called the DataTreasury™ System. The DataTreasury™ System provides comprehensive support for the processing of documents and electronic data associated with different applications including sale, business, banking and general consumer transactions. The system retrieves transaction data such as credit card receipts checks in either electronic or paper form at one or more remote locations, encrypts the data, transmits the encrypted data to a central location, transforms the data to a usable form, performs identification verification using signature data and biometric data, generates informative reports from the data and transmits the informative reports to the remote location(s). The DataTreasury™ System has many advantageous features which work together to provide high performance, security, reliability, fault tolerance and low cost. First, the network architecture facilitates secure communication between the remote location(s) and the central processing facility. A dynamic address assignment algorithm performs load balancing among the system's servers for faster performance and higher utilization. Finally, a partitioning scheme improves the error correction process.

Plain-Language Overview of Independent Claims:

This patent contains one independent claim.

Claim 1: This claim describes a system for managing and verifying electronic and paper financial transactions from remote locations. The system is comprised of three main parts:

• Remote Data Access Subsystem: This is a device at a remote location (like a store) that captures data from transactions, whether they are from paper (like a receipt) or electronic (like a credit card).
• Data Collecting Subsystem: This is an intermediary system that gathers the transaction data sent from one or more of the remote devices. It has a component for managing this data collection and transmission.
• Central Data Processing Subsystem: This is a central computer system that receives the transaction data from the collecting subsystem. It is responsible for processing, sending, and storing the data. It also has a management component for these tasks.
• Communication Network: This connects all the different parts of the system, allowing them to send transaction data between the remote devices and the central processing system.

In essence, the claim outlines a networked system that allows for the capture of financial transaction information at the point of sale, collection of that information, and centralized processing and storage of the data.

CAFC Docket Search:
A search of the CAFC (Court of Appeals for the Federal Circuit) dockets for 2026 did not yield any specific results for US Patent 6,032,137. This indicates that, based on the publicly available information at the time of this search, there are no ongoing or recent appeals involving this patent in the 2026 docket. However, this does not preclude the possibility of past litigation or future disputes.

Litigation History of U.S. Patent No. 6,032,137

As of May 11, 2026, U.S. Patent No. 6,032,137, owned for many years by DataTreasury Corporation, has been the subject of extensive and significant litigation, primarily against the banking and financial services industry. DataTreasury, represented by firms including Nix Patterson, LLP and The Roach Law Firm, has reportedly recovered over $350 million through infringement lawsuits and licensing agreements related to its patents on electronic check processing. These legal actions asserted that the methods used by banks to comply with the Check 21 Act, such as remote deposit capture and image processing, infringed on the '137 patent and its family member, U.S. Patent No. 5,910,988.

The litigation campaign began in the early 2000s and involved dozens of financial institutions. The primary venue for these cases has been the U.S. District Court for the Eastern District of Texas, a jurisdiction known for its experience with patent cases.

Below is a non-exhaustive list of known litigation involving this patent.

District Court Litigation

• Plaintiff: DataTreasury Corporation

• Defendants: Wells Fargo & Company, Wells Fargo Bank, N.A., and numerous other financial institutions (including Bank of America, Wachovia, U.S. Bancorp, Suntrust, and many more).

• Jurisdiction: U.S. District Court for the Eastern District of Texas

• Case Number: 2:06-cv-00072

• Filing Date: February 24, 2006

• Status/Outcome: This consolidated case involved a large number of defendants. The litigation was complex, featuring motions to stay, severance, and an appeal to the Federal Circuit regarding an arbitration clause which was ultimately denied. Many defendants settled with DataTreasury over the years. For instance, JPMorgan Chase entered a consent judgment in 2005 acknowledging the patents' validity and enforceability and took a license.

• Plaintiff: DataTreasury Corporation

• Defendant: Bank of America Corporation, et al.

• Jurisdiction: U.S. District Court for the Eastern District of Texas

• Case Number: 2:05-cv-00292

• Filing Date: July 26, 2005

• Status/Outcome: This case, along with others filed around the same time against institutions like Citigroup and Wachovia, was a precursor to the larger consolidated '072 case. A trial against Bank of America resulted in a settlement during the proceedings.

• Plaintiff: DataTreasury Corporation

• Defendants: Fidelity National Information Services Inc. (FIS), Fiserv Inc., and their respective client banks.

• Jurisdiction: U.S. District Court for the Eastern District of Texas

• Case Number: Case numbers for these specific 2013 actions include 2:13-cv-00431, 2:13-cv-00432, and 2:13-cv-00433.

• Filing Date: May 28, 2013

• Status/Outcome: These lawsuits represented a later wave of enforcement, targeting not just banks but also the software and service providers that supplied the allegedly infringing technology. The outcome often involved licensing agreements.

Patent Trial and Appeal Board (PTAB) Proceedings

The validity of the '137 patent was also challenged at the U.S. Patent and Trademark Office. These challenges are a form of litigation intended to invalidate a patent's claims.

• Proceeding: Covered Business Method (CBM) Review

• Case Numbers: CBM2014-00020, CBM2014-00056, CBM2014-00088

• Filing Dates: 2013-2014

• Status/Outcome: Final Written Decisions were issued in these cases. CBM reviews were a specific type of proceeding for challenging patents related to financial products or services. These proceedings, along with inter partes re-examinations, were part of the effort by accused infringers to invalidate the patent claims.

• Proceeding: Inter Partes Review (IPR)

• Case Number: IPR2014-00490

• Filing Date: 2014

• Status/Outcome: This petition was not instituted, meaning a trial did not proceed on the merits, which was a favorable outcome for the patent owner in this specific instance.

The information for these cases is cited from the litigation history provided by Google Patents and Unified Patents, accessible via the authoritative patent text link. (Source: https://patents.google.com/patent/[US6032137](/patent/US6032137)/en)

Based on a review of public records, including the USPTO Patent Trial and Appeal Board (PTAB) database and litigation data, there has been significant post-grant activity concerning US Patent 6,032,137.

Proceedings overview

Four AIA trial proceedings were filed against US patent 6,032,137, including three Covered Business Method (CBM) reviews and one Inter Partes Review (IPR). The patent owner disclaimed all claims (1-21) in the IPR, and three separate CBM panels subsequently issued Final Written Decisions finding all claims unpatentable. This gives a defendant an exceptionally strong defensive posture, as all claims of the patent have been canceled and/or invalidated.

IPR2014-00490 — Unified Patents Inc. v. DataTreasury Corp.

• Type: Inter Partes Review
• Filed: 2014-03-12
• Status: Terminated. The Patent Owner filed a statutory disclaimer for all claims of the '137 patent and requested an adverse judgment, leading to the termination of the proceeding.
• Judge panel: Not applicable, as the case was terminated before an institution decision.
• Petition grounds: The petition challenged claims 1-21 based on prior art under 35 U.S.C. §§ 102 and 103.
• Institution decision: An institution decision was not rendered. The proceeding was terminated on 2014-04-22 after the Patent Owner's request for adverse judgment and disclaimer of all claims.
• Final Written Decision: Not applicable.
• Settlement / termination: The case was terminated due to the Patent Owner's disclaimer of all claims (1-21). This action has the legal effect of canceling the claims from the patent.
• Appeal: Not applicable.
• Defensive value: This proceeding is dispositive. The patent owner's statutory disclaimer of all claims renders the patent unenforceable. Any infringement theory built on any claim of US Patent 6,032,137 is baseless.

CBM2014-00020 — SAP America, Inc. v. DataTreasury Corp.

• Type: Covered Business Method Review
• Filed: 2013-11-18
• Status: Final Written Decision - Claims Invalidated.
• Judge panel: Administrative Patent Judges Lora M. Green, Michael W. Bisk, and Bart A. Gerstenblith.
• Petition grounds: Claims 1-21 were challenged as being directed to patent-ineligible subject matter under 35 U.S.C. § 101.
• Institution decision: Institution was granted on 2014-04-17. The Board found the patent eligible for CBM review and determined it was more likely than not that the challenged claims were unpatentable under § 101.
• Final Written Decision: A Final Written Decision was issued on 2015-04-16, canceling all challenged claims. The panel concluded that claims 1-21 are directed to the abstract idea of managing data and lack an inventive concept sufficient to transform the idea into a patent-eligible application. The decision states, "we determine that Petitioner has shown by a preponderance of the evidence that claims 1–21 of the ’137 patent are unpatentable under 35 U.S.C. § 101."
• Settlement / termination: No settlement was reached; the case proceeded to a final decision.
• Appeal: The FWD was appealed to the Federal Circuit. The outcome of the related CBM proceedings rendered the appeal moot.
• Defensive value: This proceeding provides an independent basis for the invalidity of all claims of the '137 patent. It confirms that the claims are directed to an abstract idea and are unpatentable under § 101.

CBM2014-00056 — PNC Financial Services Group, Inc. et al. v. DataTreasury Corp.

• Type: Covered Business Method Review
• Filed: 2014-01-08
• Status: Final Written Decision - Claims Invalidated.
• Judge panel: Administrative Patent Judges Michael P. Tierney, Gregg I. Anderson, and Georgianna W. Braden.
• Petition grounds: Claims 1-21 were challenged as being directed to patent-ineligible subject matter under 35 U.S.C. § 101.
• Institution decision: Institution was granted on 2014-06-23.
• Final Written Decision: A Final Written Decision was issued on 2015-06-19, canceling all challenged claims (1-21) as unpatentable under 35 U.S.C. § 101. The Board found the claims were directed to the abstract idea of collecting and storing data.
• Appeal: The decision was appealed to the Federal Circuit, but the appeal was ultimately dismissed.
• Defensive value: This is the second FWD finding all claims of the patent unpatentable on § 101 grounds, further cementing their invalidity.

CBM2014-00088 — Fiserv, Inc. et al. v. DataTreasury Corp.

• Type: Covered Business Method Review
• Filed: 2014-03-12
• Status: Final Written Decision - Claims Invalidated.
• Judge panel: Administrative Patent Judges Lora M. Green, Michael W. Bisk, and Bart A. Gerstenblith.
• Petition grounds: Claims 1-21 were challenged as being directed to patent-ineligible subject matter under 35 U.S.C. § 101.
• Institution decision: Institution was granted on 2014-09-09.
• Final Written Decision: A Final Written Decision was issued on 2015-09-08, canceling all challenged claims (1-21) as unpatentable under 35 U.S.C. § 101.
• Appeal: No appeal information is readily available, likely because the patent was already invalidated in multiple other proceedings.
• Defensive value: This is the third FWD invalidating all claims of the patent, leaving no doubt as to their unenforceability.

Strategic summary

The claims of US Patent 6,032,137 are unequivocally CANCELED and unenforceable. The Patent Owner's statutory disclaimer in IPR2014-00490 effectively removed all claims from the patent. This was followed by three separate Final Written Decisions in CBM proceedings (CBM2014-00020, CBM2014-00056, CBM2014-00088), each independently concluding that all claims (1-21) are unpatentable under 35 U.S.C. § 101 as being directed to an abstract idea.

Because all claims have been canceled, the estoppel landscape is moot for any future defendant; there are no surviving claims to assert. The pattern of activity shows a concerted effort by multiple parties in the financial services and software industries, as well as by defensive aggregator Unified Patents, to challenge the validity of this patent, which was being broadly asserted. The result was a complete and total victory for the petitioners.

Recommended next steps

If you are a defendant facing an assertion of US Patent 6,032,137, your position is exceptionally strong. The patent is unenforceable.

• You should immediately point the asserting party to the public record of IPR2014-00490, in which the Patent Owner, DataTreasury Corp., filed a statutory disclaimer of all claims.
• You should also cite the three subsequent Final Written Decisions from the PTAB, which independently invalidate all claims. For example, in CBM2014-00020, the Board's conclusion is unambiguous:

  "For the foregoing reasons, we determine that Petitioner has shown by a preponderance of the evidence that claims 1–21 of the ’137 patent are unpatentable under 35 U.S.C. § 101." (Final Written Decision, CBM2014-00020, Paper 35, Page 29, available at https://ptab.uspto.gov/)

• Continued assertion of this patent in light of its PTAB history could be grounds for sanctions under Federal Rule of Civil Procedure 11. There are no active proceedings because there are no longer any valid claims to adjudicate.

Inventors

• Claudio R. Ballard: The sole inventor. At the time of filing, the patent was assigned to CSP Holdings LLC, a company Ballard controlled. This pattern is common for individual inventors who set up a corporate entity to hold their intellectual property before seeking funding or beginning an assertion campaign.

Original assignee

• CSP Holdings LLC: This was a Delaware limited liability company and appears to have been a holding entity for the inventor, Claudio Ballard. The patent text itself refers to the invention as the "DataTreasury™ System," indicating that the branding and concept were developed in concert with the patent filing. There is no evidence that CSP Holdings LLC ever commercialized or shipped a product embodying the claims. The entity's purpose seems to have been to hold the initial patent, which was later transferred to DataTreasury Corporation, the entity that would go on to enforce it.

Assignment timeline

A chronological list of assignments recorded with the USPTO is provided below.

• 1998-05-19 (executed) / recorded 1998-05-27 — Reel 009226/0833

  • Conveyance: Assignment
  • Assignor: Claudio R. Ballard
  • Assignee: CSP Holdings, L.L.C.
  • Correspondent: Baker & Botts, LLP, Washington, DC
  • Context: The inventor assigned his invention to his holding company at the time of filing.

• 2002-06-24 (executed) / recorded 2002-07-22 — Reel 012882/0157

  • Conveyance: Assignment
  • Assignor: CSP Holdings, L.L.C.
  • Assignee: DataTreasury Corporation
  • Correspondent: Kenyon & Kenyon, New York, NY
  • Context: The patent was transferred from the inventor's initial holding company to the new corporate entity that would serve as the primary assertion vehicle.

• 2003-08-08 (executed) / recorded 2003-08-11 — Reel 014131/0088

  • Conveyance: Assignment of Interest and Lien Against Enforcement Actions
  • Assignor: Data Treasury Corporation
  • Assignee: Shore Deary, L.L.P
  • Correspondent: Otis W. Carroll, Ireland, Carroll & Kelley, P.C., Amarillo, TX
  • Context: This appears to be a security agreement, likely granting the law firm of Shore Deary a financial interest in the proceeds of any litigation involving the patent, possibly as part of a contingency-fee representation agreement.

• 2003-09-22 (executed) / recorded 2003-09-24 — Reel 014283/0365

  • Conveyance: Disclaimer of Assignment
  • Assignor: Data Treasury Corporation
  • Assignee: Shore Deary, L.L.P.
  • Correspondent: Otis W. Carroll, Ireland, Carroll & Kelley, P.C., Amarillo, TX
  • Context: A formal disclaimer clarifying or possibly terminating the previously recorded security interest. This was followed by a similar recording two days later.

Timeline diagram

timeline
    title Ownership of US 6032137
    1998 : Inventor assigns patent to CSP Holdings LLC
    2000 : Patent issues
    2002 : Assigned to DataTreasury Corporation
    2003 : Security interest granted to Shore Deary LLP
         : First infringement suits filed by DataTreasury
         : Security interest disclaimed

NPE / troll-pattern signals

1. Shell-entity transfer: Present. The patent was moved from CSP Holdings LLC, which had no evident products, to DataTreasury Corporation in June 2002. DataTreasury Corporation then commenced a large-scale litigation campaign starting in 2003, making its primary business the assertion of its patent portfolio. (Reel 012882/0157)

2. Known asserter in the chain: Present. DataTreasury Corporation is a widely-known and prolific patent assertion entity. Its litigation campaigns, particularly against the banking industry, are well-documented by industry trackers like Unified Patents.

3. Repeat correspondent across the chain: Not present. The major transfers (inventor to LLC, LLC to corporation) were handled by different major law firms. The security agreement was handled by a third firm. This is not a signal here.

4. Cascading transfers: Not present. The ownership chain is direct from the inventor's entities.

5. Pre-litigation transfer: Present. The assignment to DataTreasury Corporation was executed on June 24, 2002 (Reel 012882/0157). The first lawsuits asserting the patent were filed in early 2003, well within the 6-month window and indicating a clear preparation for an assertion campaign.

6. Bankruptcy fire-sale: Not present.

7. Privateering: Not present. The asserting entity was founded and controlled by the patent's inventor, not a third-party firm acting on behalf of an operating company.

8. Defensive aggregator (anti-NPE): Not present. The patent has not been acquired by any known defensive entity.

Verdict

• NPE — high confidence

The assignment history of US 6,032,137 shows multiple strong signals of NPE activity. The patent was transferred to DataTreasury Corporation (Reel 012882/0157), a well-known patent assertion entity founded by the inventor, shortly before the commencement of a massive litigation campaign. This pre-litigation transfer to a known asserter, which appears to have been formed for the purpose of monetizing this patent portfolio, provides high confidence in classifying this patent as an NPE-held asset.

Verification Link: USPTO Patent Assignment Search for Pat. No. 6,032,137

Based on a review of the references cited during the prosecution of US Patent 6,032,137, the following prior art is identified as most relevant to the patent's claims, particularly independent claim 1. The analysis focuses on potential anticipation under 35 U.S.C. § 102, which requires a single prior art reference to disclose every element of a claimed invention.

Most Relevant Prior Art

The most relevant cited reference appears to be US 5,870,723. It describes a system for converting paper-based transactions, such as checks, into electronic transactions at a remote point of sale, which closely aligns with the system claimed in the '137 patent. Other references, such as US 5,283,829 and US 5,602,933, are also highly relevant as they disclose systems for remote data capture and central verification.

---

Detailed Analysis of Key Prior Art References

1. U.S. Patent 5,870,723 A

• Full Citation: Pare, Jr. et al., "System for managing and conducting a paper-based transaction as an electronic transaction"
• Publication Date: February 9, 1999
• Filing Date: August 8, 1996
• Brief Description: This patent discloses a system and method for processing paper checks as electronic transactions at the point of sale. A remote terminal at a merchant location scans a check, captures data (account number, amount), transmits this data through a network for authorization, and converts the transaction into an electronic funds transfer (EFT). The system utilizes existing financial networks, which include intermediary processors, to connect the remote merchant to a central clearinghouse for settlement.
• Potential Anticipation of Claim 1: This patent appears to disclose all elements of claim 1 of the '137 patent.
  • "at least one remote data access subsystem for capturing and sending... transaction data": The point-of-sale terminal with a check scanner in the '723 patent directly corresponds to this element. It captures data from a paper transaction and sends it electronically.
  • "at least one data collecting subsystem for collecting and sending the... transaction data": The '723 patent describes transmitting data through a "transaction network," which in the context of financial transactions includes acquirers or processors that collect data from multiple merchants before forwarding it. This intermediary function aligns with the claimed "data collecting subsystem."
  • "at least one central data processing subsystem for processing, sending and storing the... transaction data": The "clearing house computer system" described in the '723 patent serves this function. It receives transaction data from the network, processes it for settlement between financial institutions, and stores transaction records.
  • "at least one communication network": The patent explicitly describes a "transaction network" connecting the remote terminals to the central clearinghouse.

2. U.S. Patent 5,283,829 A

• Full Citation: Anderson, "Method for verifying the authenticity of documents in a data processing system"
• Publication Date: February 1, 1994
• Filing Date: July 31, 1992
• Brief Description: The '829 patent describes a system for verifying the authenticity of documents like checks at a point-of-sale terminal. The system involves a terminal that scans a document, extracts features (such as a signature), transmits the extracted data to a central host computer, and compares the data against a master file for verification.
• Potential Anticipation of Claim 1: This reference is highly relevant but may not fully disclose the intermediate "data collecting subsystem."
  • "remote data access subsystem": Disclosed as the point-of-sale terminal with a scanner.
  • "central data processing subsystem": Disclosed as the central host computer that performs the verification and stores the master reference file.
  • "communication network": Implicitly disclosed as the means of communication between the terminal and the central host.
  • "data collecting subsystem": The '829 patent appears to describe a two-tier (remote-to-central) architecture. It is not explicit about an intermediate subsystem that collects data from multiple remote sites before forwarding it to the central processor. This potential distinction may prevent a finding of direct anticipation.

3. U.S. Patent 5,602,933 A

• Full Citation: Kageyama, "Data verification system and data verification method"
• Publication Date: February 11, 1997
• Filing Date: May 26, 1995
• Brief Description: This patent details a system for ensuring the integrity of data captured at a remote location. A remote terminal acquires data, encrypts it, and transmits it over a communication line to a central facility. The central facility then compares the received data with master data stored centrally to verify its authenticity.
• Potential Anticipation of Claim 1: Similar to the '829 patent, this reference teaches a remote-to-central architecture but lacks a clear disclosure of the intermediate tier.
  • "remote data access subsystem": Disclosed as the remote terminal that acquires and encrypts data.
  • "central data processing subsystem": Disclosed as the "central facility" which stores master data and performs the verification.
  • "communication network": Disclosed as the communication line between the remote and central locations.
  • "data collecting subsystem": The architecture described does not explicitly include an intermediary collector, making direct anticipation of this element unlikely.

Obviousness Analysis of U.S. Patent No. 6,032,137 under 35 U.S.C. § 103

This analysis evaluates whether the invention claimed in U.S. Patent No. 6,032,137 would have been obvious to a Person Having Ordinary Skill in the Art (PHOSITA) at the time of the invention, with a priority date of August 27, 1997. A PHOSITA in this context would be an individual with a degree in computer science or electrical engineering and several years of experience in designing and implementing distributed data processing systems, particularly for financial transactions.

The analysis focuses on independent claim 1, as all other claims are dependent upon it.

---

Deconstruction of Independent Claim 1

Claim 1 describes a system with four key functional blocks:

1. Remote Data Access Subsystem: A terminal at a remote location (e.g., a merchant) that captures both paper and electronic transaction data and sends it.
2. Data Collecting Subsystem: An intermediate server that collects data from multiple remote subsystems and forwards it.
3. Central Data Processing Subsystem: A central server that receives data from the collecting subsystem(s) for final processing and storage.
4. Communication Network: The infrastructure connecting all subsystems.

The core of the claimed invention is a three-tiered network architecture (remote terminal -> intermediate collector -> central processor) applied to the specific problem of aggregating both scanned paper documents and electronic transaction data.

---

Prior Art and Motivation to Combine

The claims of US 6,032,137 are rendered obvious by combinations of prior art that existed before the patent's priority date. The motivation to combine these references would have been driven by clear business needs and well-established engineering principles for creating scalable and efficient distributed systems.

Combination 1: Henderson (US 5,544,256) and Known Three-Tier Architectural Principles

A strong argument for obviousness can be made by combining the teachings of U.S. Patent No. 5,544,256 ("Henderson") with the common knowledge of three-tier network architectures prevalent in the mid-1990s.

• Reference: U.S. Patent 5,544,256 to Henderson et al. (filed Jan. 21, 1994; issued Aug. 6, 1996).

  • What it Teaches: Henderson discloses a "remote document processing" system specifically for financial documents like checks. It explicitly teaches:
    • A remote data access subsystem (a terminal with a scanner) for capturing images of paper documents (Claim 1, element 1).
    • A central data processing subsystem (a "central host") for receiving, processing, and storing the document images and associated data (Claim 1, element 3).
    • A communication network (e.g., a telephone line) to transmit the data from the remote terminal to the central host (Claim 1, element 4).
  • What it Lacks: Henderson describes a two-tier (client-server) architecture. It does not explicitly disclose the intermediate Data Collecting Subsystem (Claim 1, element 2).

• Motivation to Combine with Known Principles:
  A PHOSITA tasked with deploying Henderson's remote document capture system on a large scale (e.g., for a national bank with thousands of branches or a large retail chain) would have immediately encountered a significant scalability problem. Having thousands of remote terminals connect directly to a single central host, often over slow dial-up connections, would create an immense bottleneck, reduce reliability, and be difficult to manage.

  By 1997, the use of a three-tier (or n-tier) architecture was a standard, textbook solution to this exact problem. An intermediate "collector" or "concentrator" tier was commonly used to:

  1. Aggregate Connections: Offload the burden of managing thousands of individual connections from the central server.
  2. Improve Efficiency: Poll remote terminals during off-peak hours (as described in the '137 patent at col. 10, ll. 3-5) and forward the collected data to the central host in optimized, high-speed batches.
  3. Enhance Reliability: Provide regional fault tolerance. If the link to the central processor went down, the regional collector could continue to gather data from its remote terminals.

  Therefore, adding an intermediate "data collecting subsystem" to the system taught by Henderson would have been an obvious architectural choice for a PHOSITA seeking to build a robust, scalable version of Henderson's system. It represents the application of a known technique (three-tier architecture) to a known system (Henderson's) to achieve a predictable result (improved scalability and efficiency).

Combination 2: Olsen (US 5,479,510) in view of Henderson (US 5,544,256)

This combination establishes the obviousness of creating a single system for both electronic and paper transactions, which could then be scaled using the principles described above.

• Reference: U.S. Patent 5,479,510 to Olsen (filed Dec. 29, 1993; issued Dec. 26, 1995).

  • What it Teaches: Olsen discloses a point-of-sale system that captures and transmits electronic purchaser and transaction information to a central location for storage and later verification. This teaches the core elements of the '137 patent for electronic data: a remote subsystem, a central subsystem, and a network.
  • What it Lacks: Olsen does not teach the processing of paper documents.

• Motivation to Combine:
  A PHOSITA would recognize that point-of-sale environments generate both electronic transactions (e.g., credit card authorizations as in Olsen) and paper documents (e.g., checks, signed receipts). A business would have a clear motivation to create a unified system to capture and archive all transaction data, regardless of its source, to simplify record-keeping, analysis, and auditing.

  Henderson ('256) provides the missing piece by teaching a system for remotely scanning and processing paper financial documents. It would have been obvious to a PHOSITA to integrate the paper-scanning capabilities of Henderson's system with the electronic transaction system of Olsen. This combination would result in a single, unified remote terminal capable of handling both data types, thus creating the "remote data access subsystem for capturing and sending electronic and paper transaction data" as recited in Claim 1. Once this unified two-tier system was conceived, the same motivation to add an intermediate collection tier for scalability would apply as outlined in Combination 1.

Conclusion

The individual elements of the system claimed in US 6,032,137 were well-known in the prior art before August 1997. Systems for remote electronic data capture and central storage were known (e.g., Olsen), as were systems for remote paper document capture and central processing (e.g., Henderson).

The primary inventive thrust of the '137 patent appears to be the specific three-tiered architecture. However, this architecture was a conventional design pattern used to solve predictable scalability and performance issues in distributed systems. A person of ordinary skill in the art, when faced with the task of building a large-scale transaction processing system based on the teachings of prior art like Henderson and Olsen, would have been motivated to introduce an intermediate collection tier to improve performance and reliability. Such a modification would have been considered an obvious and routine application of established computer networking principles.

This conclusion is consistent with the subsequent invalidation of all claims of the '137 patent by the PTAB (e.g., CBM2014-00020, CBM2014-00056), which found the claims were directed to the abstract idea of data management implemented using conventional technology—a finding that aligns with the argument that the claimed configuration would have been obvious.

Patent Term and Expiration

Projected Expiration Date:
U.S. Patent 6,032,137 expired on August 27, 2017.

The patent's term was calculated based on the filing date of its parent application, not its own filing date. As stated in the "Cross-Reference to Related Applications" section of the patent specification, "This application is a continuation in part of application Ser. No. 08/917,761 filed Aug. 27, 1997, now U.S. Pat. No. 5,910,988."

Under U.S. patent law, the term of a patent that is part of a family of continuing applications is 20 years from the earliest non-provisional filing date for which a benefit is claimed. In this case, the earliest priority date is August 27, 1997. Therefore, the 20-year term concluded on August 27, 2017. The legal status of the patent is listed as "Expired - Lifetime" in public databases, confirming it is no longer in force.

Patent Term Adjustment (PTA) / Patent Term Extension (PTE):
There were no Patent Term Adjustments or Extensions granted for this patent. The patent's term was governed by the 20-year calculation from its priority date.

Continuity and Patent Family

US Patent 6,032,137 is a key member of a large and heavily litigated family of patents, often referred to as the "Ballard patents" or the "DataTreasury patents."

Parent Application (Continuity Data):

• Type: Continuation-in-Part
• Parent Application: 08/917,761 (Filed: August 27, 1997)
• Parent Patent: The parent application issued as U.S. Patent 5,910,988 on June 8, 1999. This '988 patent was frequently asserted alongside the '137 patent in DataTreasury's litigation campaigns.

Child Applications (Continuations):
The application for the '137 patent (09/081,012) served as the basis for several subsequent continuation applications, which extended the family and the scope of claimed inventions. Notable continuations include:

• U.S. Patent 8,024,269: Filed December 6, 1999, as a continuation of the application leading to the '137 patent.
• U.S. Patent 7,519,558: Filed September 17, 2002, as a continuation.
• U.S. Patent 8,494,963: Filed September 19, 2011, as a continuation.

This family tree demonstrates a common patent strategy of filing a series of continuing applications to build a broad portfolio around a core invention, which can then be used for licensing or enforcement.

International Family Members:
The inventor also sought broad international protection. The U.S. application served as a priority document for numerous international filings, including applications in Europe (EP1008086A4), China (CN1319006C), Japan (JP2001514423A), and via the Patent Cooperation Treaty (PCT) with publication number WO1999011021A2. This widespread filing indicates an early intent to establish a global intellectual property position.

Defensive Disclosure: Derivative Embodiments and Obvious Variations of a Three-Tiered Remote Data Capture System.

Publication Date: April 26, 2026
Reference Patent: US 6,032,137
Abstract: This document discloses a series of derivative inventions, technical variations, and cross-domain applications of a networked system comprising remote data capture, intermediate data collection, and central data processing. The purpose of this disclosure is to place these variations into the public domain to serve as prior art against future patent applications claiming these or substantially similar concepts.

---

I. Derivative Variations based on Core Claim 1

1. Material & Component Substitution

Derivative 1.1: Mobile-First, Optically-Driven Remote Data Access Subsystem

• Enabling Description: The remote data access subsystem is embodied not as a dedicated hardware terminal (NC), but as a software application running on a commercial off-the-shelf (COTS) mobile device, such as a smartphone or ruggedized tablet. The data capture function, previously performed by a mechanical scanner, is replaced by the device's integrated high-resolution CMOS camera. The application uses an embedded computer vision library (e.g., OpenCV, Tesseract OCR) to perform real-time, on-device document scanning, feature extraction (including MICR line data from checks), and perspective correction. Biometric data (e.g., a handwritten signature) is captured via the device's capacitive touchscreen. The DAT modem component is replaced by a multi-modal wireless transceiver utilizing 5G NR (New Radio) for high-bandwidth, low-latency communication, with failover to a Low-Power Wide-Area Network (LPWAN) protocol such as LoRaWAN for essential data when out of cellular range.

• Diagram:

  graph TD
      subgraph Mobile Remote Subsystem (DAT)
          A[COTS Mobile Device] --> B{Software Application};
          B --> C[CMOS Camera];
          B --> D[Capacitive Touchscreen];
          B --> E[Multi-Modal 5G/LoRaWAN Transceiver];
          C -- Raw Image Frame --> F[On-Device CV/OCR Engine];
          D -- Stylus/Finger Input --> G[Biometric Signature Vectorization];
          F -- Extracted Text & Metadata --> H[Payload Encryption Module];
          G -- Vector Data --> H;
          H -- Encrypted Packet --> E;
      end
      E --> I((Data Collecting Subsystem));
  

Derivative 1.2: Solid-State, Thermoelectrically-Cooled Collector Subsystem

• Enabling Description: The data collecting subsystem (DAC), designed for high-reliability edge computing environments, is constructed as a fanless, solid-state server. The DEC Alpha servers are replaced with passively-cooled ARM-based System-on-a-Chip (SoC) clusters. Data storage is implemented using NVMe (Non-Volatile Memory Express) solid-state drives in a RAID 10 configuration, eliminating mechanical failure points associated with spinning hard drives. To ensure stable operation in environments with high ambient temperatures (e.g., a factory floor or a sealed telecommunications enclosure), the entire chassis is hermetically sealed and thermal regulation is achieved via Peltier-effect thermoelectric cooling (TEC) modules coupled with external heat sinks. Power is supplied via Power over Ethernet (PoE++) and backed by a local supercapacitor bank instead of a traditional UPS, providing instantaneous failover for short-term power loss.

• Diagram:

  graph LR
      subgraph Solid-State Collector (DAC)
          A[PoE++ Input] --> B[Supercapacitor Bank];
          A --> C[ARM SoC Cluster];
          D[NVMe RAID 10 Array] -- PCIe --> C;
          E[Thermoelectric Cooling Modules] -- Manages Temp --> C;
          E -- Manages Temp --> D;
          C -- Data I/O --> F[Network Interface];
      end
      G((Remote Subsystems)) -- Data --> F;
      F -- Data --> H((Central Processor));
  

2. Operational Parameter Expansion

Derivative 2.1: Microfluidic Transaction System for Lab-on-a-Chip Analytics

• Enabling Description: The invention is scaled down to operate at the microfluidic level for automated laboratory diagnostics. The "remote data access subsystem" is a microfluidic chip with integrated biosensors. A "transaction" is defined as the analysis of a single biological sample (e.g., a drop of blood). The chip captures data by measuring electrical impedance, fluorescence, or colorimetric changes. This analog sensor data is digitized on-chip by a micro-controller unit (MCU). The "data collecting subsystem" is a benchtop analysis instrument that houses multiple microfluidic chips, polling each one for its results and aggregating the data. The "central data processing subsystem" is a Laboratory Information Management System (LIMS) server that receives the aggregated batch data, archives it against patient records, and performs trend analysis across thousands of samples. The communication network between the chip and the instrument is a Serial Peripheral Interface (SPI) bus, while the instrument communicates with the LIMS via a standard TCP/IP network.

• Diagram:

  sequenceDiagram
      participant R as Remote (Microfluidic Chip)
      participant C as Collector (Benchtop Instrument)
      participant P as Central Processor (LIMS)
      R->>R: Analyzes biological sample
      R->>C: Sends digitized sensor data via SPI bus
      C->>C: Aggregates data from multiple chips
      C->>P: Transmits encrypted batch results via TCP/IP
      P->>P: Stores data and performs analysis
      P-->>C: Sends new analysis parameters
  

Derivative 2.2: Global Logistics System Operating Over High-Latency Satellite Networks

• Enabling Description: The system is adapted for managing logistics data from intermodal shipping containers in remote or transoceanic locations. The remote subsystem is a device affixed to each container, equipped with GPS, and sensors for shock, temperature, and humidity. It communicates via a low-throughput, high-latency satellite communication link (e.g., Iridium or Starlink IoT). Due to the high cost and latency of satellite data, the remote subsystem performs significant on-board data compression and aggregation, only transmitting a "heartbeat" summary packet at predefined intervals (e.g., once every 6 hours). The "data collecting subsystem" is a cloud-based gateway service provided by the satellite network operator, which receives these packets from thousands of containers, buffers them, and exposes them to the central processor via a message queue API. The "central data processing subsystem" is the logistics company's global tracking and analytics platform, which consumes the data to provide real-time visibility and predictive ETAs. The system is designed to tolerate network outages of up to 72 hours, with the remote subsystem caching all sensor readings in local flash memory.

• Diagram:

  graph TD
      A[Container Sensor Unit] -- Satellite Uplink --> B(Satellite Network);
      B -- Ground Station --> C[Cloud Gateway API];
      subgraph Remote Subsystem
          A
      end
      subgraph Collector Subsystem
          C
      end
      C -- Message Queue --> D[Global Logistics Platform];
      subgraph Central Processor
          D
      end
      D -- Analytics --> E[Customer Dashboard];
  

3. Cross-Domain Application

Derivative 3.1: Aerospace - Aircraft Component Lifecycle Management

• Enabling Description: The system is applied to track the service history of critical aircraft components.

  • Remote Subsystem: A handheld device used by an aircraft maintenance engineer on the tarmac. It uses a combination of a barcode/QR code scanner and NFC reader to identify a component (e.g., a turbine blade). The engineer inputs maintenance actions, and the device captures a digital signature and biometric thumbprint for attribution.
  • Collector Subsystem: The airport's Maintenance, Repair, and Overhaul (MRO) server. It collects data from all maintenance devices on-site via a secure Wi-Fi network and synchronizes it with the central system.
  • Central Processor: The aircraft manufacturer's (e.g., Airbus A350) global digital twin database. It processes the incoming data to update the lifecycle record for that specific serialized component, schedules future inspections, and performs fleet-wide predictive failure analysis.

• Diagram:

  erDiagram
      AIRCRAFT_COMPONENT {
          string ComponentID PK
          string Type
          int FlightHours
      }
      MAINTENANCE_RECORD {
          string RecordID PK
          string ComponentID FK
          string MRO_Server_ID FK
          datetime Timestamp
          string ActionTaken
          blob EngineerSignature
      }
      MRO_SERVER {
          string MRO_Server_ID PK
          string AirportCode
      }
      AIRCRAFT_COMPONENT ||--o{ MAINTENANCE_RECORD : "has"
      MRO_SERVER ||--o{ MAINTENANCE_RECORD : "collects"
  

Derivative 3.2: AgTech - Precision Agriculture Data Aggregation

• Enabling Description: The system is used for managing data in a smart farming operation.

  • Remote Subsystem: An IoT sensor package mounted on an autonomous tractor. It captures soil nutrient data (N, P, K), moisture levels, high-resolution imagery of crops for pest detection, and GPS location data.
  • Collector Subsystem: An on-farm edge computing server located in the barn. It receives data from tractors, drones, and stationary soil sensors via a local mesh network (e.g., Zigbee or Wi-Fi HaLow). It performs initial data filtering and compression.
  • Central Processor: A cloud-based agricultural analytics platform. It aggregates data from hundreds of farms, combines it with weather satellite data, and uses machine learning to generate variable-rate fertilizer application prescriptions, which are then sent back to the farm equipment.

• Diagram:

  flowchart LR
      subgraph Remote
          A[Tractor Sensor Array]
      end
      subgraph Collector
          B[On-Farm Edge Server]
      end
      subgraph Central
          C[Cloud Analytics Platform]
      end
      A -- Zigbee/Wi-Fi --> B;
      B -- Internet --> C;
      C -- ML Model --> D[Fertilizer Prescription];
      D --> A;
  

4. Integration with Emerging Tech

Derivative 4.1: AI-Enhanced Real-Time Fraud Prevention

• Enabling Description: The system is integrated with an AI/ML pipeline for fraud detection. The remote data access subsystem captures transaction data as before. The data collecting subsystem (DAC), instead of merely aggregating data, runs a lightweight, pre-trained anomaly detection model (e.g., an autoencoder) at the edge. This model flags transactions with anomalous characteristics (e.g., unusual time, location, or amount for that specific terminal) and assigns them a preliminary risk score. The full data packet, along with the risk score, is forwarded to the central data processing subsystem (DPC). The DPC uses a more complex, deep learning model (e.g., a Graph Neural Network analyzing the relationship between merchants, customers, and locations) to perform a final risk assessment. The system uses federated learning to continuously update the edge models on the DACs without exposing raw transaction data from different regions to each other.

• Diagram:

  sequenceDiagram
      actor User
      participant DAT
      participant DAC
      participant DPC
      User->>DAT: Initiates Transaction
      DAT->>DAC: Send Transaction Data
      DAC->>DAC: Run Edge Anomaly Model
      DAC->>DPC: Forward Data + Edge Risk Score
      DPC->>DPC: Run Central GNN Fraud Model
      DPC-->>DAT: Return Approval/Denial/Challenge
      DPC->>DAC: Periodically Push Updated Edge Model
  

Derivative 4.2: Blockchain-Anchored Audit Trail for Supply Chain

• Enabling Description: The system leverages a private, permissioned blockchain (e.g., Hyperledger Fabric) to provide an immutable audit trail. When a transaction (e.g., the scanning of a bill of lading for a pharmaceutical shipment) is captured by the remote subsystem, it is transmitted to the collector. The central processing subsystem validates the transaction against business rules (e.g., ensuring the shipment temperature remained within limits, using integrated IoT sensor data). Upon validation, the DPC does not store the full image data on-chain. Instead, it computes a cryptographic hash (SHA-256) of the Tagged Encrypted Compressed Bitmap Image (TECBI) and stores this hash, along with key metadata (timestamp, GPS location, custodian ID), as a transaction on the blockchain. The full TECBI is stored in an off-chain distributed file system (like IPFS), with its content-addressable link included in the on-chain record. This provides a tamper-proof, auditable record of the transaction without bloating the blockchain with large image files.

• Diagram:

  graph TD
      A[Remote Subsystem captures Image] --> B{Central Processor};
      B -- 1. Validate Transaction --> B;
      B -- 2. Compute SHA-256 Hash --> C[Image Hash];
      B -- 3. Store Image Off-Chain --> D[(IPFS)];
      D -- Returns IPFS Link --> B;
      B -- 4. Create Blockchain Tx --> E[[Permissioned Blockchain]];
      subgraph On-Chain Transaction
          C
          F[Metadata]
          G[IPFS Link]
      end
      E -- Confirms Tx --> B;
  

5. The "Inverse" or Failure Mode

Derivative 5.1: Graceful Degradation with Store-and-Forward Protocol

• Enabling Description: The system is designed for high availability in environments with intermittent network connectivity. The remote data access subsystem operates in different states based on network health.

  • State 1: Online Mode. A stable connection exists to the data collector. The remote subsystem transmits the full TECBI immediately after capture.
  • State 2: Degraded Mode (Store-and-Forward). The connection is lost. The remote subsystem transitions to a low-power state. It captures only essential transaction text data (e.g., from OCR) and a low-resolution grayscale thumbnail of the document. This minimal data is stored locally in an encrypted SQLite database. The system can continue to process transactions in this mode for a configurable period (e.g., 24 hours or 1,000 transactions).
  • State 3: Synchronization Mode. When the network connection is restored, the remote subsystem establishes a handshake with the collector, transmits its queue of stored transactions, and then purges its local cache upon successful receipt confirmation.

• Diagram:

  stateDiagram-v2
      [*] --> Online
      Online --> Degraded: Network Loss
      Degraded --> Online: Network Restored
      Online: Transmit full TECBI in real-time
      Degraded: Store minimal data locally (Encrypted DB)
      Online: On entry / Initiate sync of queued data
  

---

II. Combination Prior Art with Open-Source Standards

Combination 1: System Architecture based on Apache Kafka

• Enabling Description: The system's data transport and collection layer is implemented using Apache Kafka, an open-source distributed event streaming platform. Each remote data access subsystem (DAT) acts as a Kafka Producer. When a document is scanned and processed, the resulting TECBI is published as a message to a specific Kafka topic, partitioned by geographical region or merchant ID (e.g., topic: us-west-transactions). The data collecting subsystem (DAC) is realized as a cluster of Kafka Brokers, which provides fault tolerance, scalability, and data persistence. The central data processing subsystem (DPC) is a distributed application (e.g., using Kafka Streams or Apache Flink) that acts as a Kafka Consumer, subscribing to the topics, processing the incoming streams of transaction data in real-time, and writing the results to a database. This architecture decouples the data capture and processing stages, allowing each to scale independently.

Combination 2: Data Payload Standardization with ISO 20022

• Enabling Description: The content of the data transmitted through the system is standardized using the ISO 20022 protocol for financial messaging. When a remote subsystem captures a paper document like a check or invoice, its on-board OCR and data extraction logic formats the extracted information into a structured XML-based ISO 20022 message. For example, a check scan would be converted into a pacs.008 (FI-to-FI Customer Credit Transfer) message. This standardized message, along with the original document image (TECBI) as an attachment, becomes the payload that is transmitted to the collector. The central processor can then natively process these messages using standard financial industry software, eliminating the need for proprietary data transformation logic.

Combination 3: Authentication and Authorization via OpenID Connect (OIDC)

• Enabling Description: The security and access control for the entire system are managed using the OpenID Connect (OIDC) and OAuth 2.0 open standards. Every remote subsystem (DAT) and every operator is registered as a client in a central Identity Provider (IdP). To initiate a session, the operator authenticates with the IdP via an OIDC flow. Upon success, the DAT receives a cryptographically signed ID Token and an Access Token. The Access Token, which contains specific scopes (e.g., write:transactions, read:config), is presented as a Bearer token with every API call from the DAT to the DAC. The DAC validates the token signature against the IdP's public key, ensuring that the request is both authenticated and authorized before accepting any data. This provides a robust, standardized, and auditable security framework for the entire network.