US 5115326

In a detailed analysis of United States Patent 5,115,326, the following information has been compiled based on USPTO records and a review of the patent documentation.

Title: Method of encoding an e-mail address in a fax message and routing the fax message to a destination on a network

Assignee: Hewlett-Packard Company

Inventors: Ken L. Burgess, John S. Marvin

Filing Date: June 26, 1990

Issue Date: May 19, 1992

Abstract:
A fax message transmitted by a facsimile transmitter includes bar coded headers in its first page. At least one of these headers contains the name of an addressee that is also a user on a network. A fax server receiving the incoming fax message inspects the first page of the incoming facsimile to locate the bar coded headers. If a TO: header is found it is used to determine the corresponding E-mail address, and the fax is automatically routed as E-mail on the network to the addressee. Any other headers, such as a FROM: or SUBJECT: header have their bar coded content converted to ASCII and attached as ASCII strings to the first page for easy inspection. An asymmetrical nature of the bar code used allows the fax server to determine which of a left-to-right or right-to-left scanning direction produces valid bar code. This in turn indicates whether the headers for the first page are right side up or upside down. By implication, this determines the orientation for the entire fax document. If the document is found to be upside down the fax server erects the document before mailing it to the addressee. The fax server or some other application running on a computer served by the network may be the addressee, and if the incoming fax is a request for information (whether by further bar code or check marks in predefined fields) the information may simply be sent by return fax to the sender, perhaps as part of the same phone call.

Independent Claims Overview:

This patent contains four independent claims. In plain language, they cover the following methods:

• Claim 1: Describes a method for a fax server to automatically route a fax message. The process involves receiving a fax, inspecting the first page for a bar-coded destination address, converting this bar code into a destination address on a network, and then sending the fax message to that network address.

• Claim 5: Outlines a method to determine the correct orientation of a received fax document. This is achieved by including an asymmetrical bar code on the first page. The fax server attempts to read this bar code from two opposing directions (e.g., left-to-right and right-to-left). Whichever direction successfully decodes the bar code reveals whether the page is right-side-up or upside-down, allowing the server to reorient the document if necessary before forwarding it.

• Claim 7: Details a method for a user to request information via fax and receive an automated response. A user sends a fax containing a bar-coded message that is a request for specific information. A fax server receives this request, interprets the bar code, and automatically takes action in response to the request.

• Claim 9: This claim describes a method for sending a document from a fax machine to a recipient on a computer network. This involves creating a cover page with the recipient's network address encoded in bar code, followed by the document pages. This entire package is then sent from a standard fax machine.

A search of the CAFC (Court of Appeals for the Federal Circuit) dockets for the year 2026 for litigation involving patent 5,115,326 yielded no results.

Litigation Search for U.S. Patent 5,115,326

As of April 29, 2026, a comprehensive search of publicly available litigation databases reveals no known litigation involving U.S. Patent 5,115,326.

The search included the Unified Patents portal, which tracks patent litigation in U.S. District Courts, the Court of Appeals for the Federal Circuit (CAFC), and the Patent Trial and Appeal Board (PTAB), as well as national case indexes accessible through the Public Access to Court Electronic Records (PACER) system. No records of complaints, petitions for inter partes review, or appeals mentioning this specific patent number were found.

Therefore, there are no litigation cases to report for US patent 5,115,326.

Proceedings overview

A comprehensive search of the USPTO's Open Data Portal and general web searches for Patent Trial and Appeal Board (PTAB) proceedings concerning U.S. Patent 5,115,326 have yielded no results. As of 2026-05-30, there are no active, concluded, or settled AIA trial proceedings (Inter Partes Review, Post-Grant Review, or Covered Business Method review) on file for this patent. This indicates that the patent's claims remain untested by the PTAB.

Strategic summary

As there are no PTAB proceedings on file, all claims of U.S. Patent 5,115,326 (claims 1-10) remain untested and fully intact. There is no estoppel landscape to consider from prior PTAB challenges, as none have occurred. The absence of PTAB activity is a notable signal, as patents that are actively asserted or of significant commercial interest often become targets for IPRs or other AIA trials.

Recommended next steps

Since no PTAB activity exists for U.S. Patent 5,115,326, there are no specific Final Written Decisions or institutional decisions to cite. For a potential defendant facing assertion of this patent today, the primary defensive strategies would lie outside the PTAB, such as in district court litigation challenging validity or non-infringement, or exploring licensing options. The lack of PTAB challenges could suggest either that the patent has not been widely asserted, or that prior art challenges were not considered viable enough to warrant a PTAB petition.

Inventors

• Ken L. Burgess (Hewlett-Packard Co)
• John S. Marvin (Hewlett-Packard Co)

No unusual patterns detected regarding inventor departures.

Original assignee

Hewlett Packard Co. was the original assignee. Hewlett-Packard was a prominent operating company in the computer and electronics industry, and it is highly likely that they shipped products embodying the claims, given their business in printers, computers, and related technologies. As of today, HP Inc. (a successor to Hewlett-Packard Co. after its 2015 split) is an operating company.

Assignment timeline

• 1991-01-07 (executed) / recorded 1991-01-07 — Reel 005822/0831
  • Conveyance: Assignment
  • Assignor: BURGESS, KEN L., MARVIN, JOHN S.
  • Assignee: HEWLETT-PACKARD COMPANY, A CORP. OF CA
  • Correspondent: NOT LISTED
  • Context: Transfer from inventors to original assignee
• 2001-01-16 (executed) / recorded 2001-01-16 — Reel 011406/0047
  • Conveyance: Merger
  • Assignor: HEWLETT-PACKARD COMPANY
  • Assignee: HEWLETT-PACKARD COMPANY
  • Correspondent: JOHN B. HAMLIN
  • Context: Internal reorganization / name change (Merger activity noted in Google Patents legal events).
• 2015-11-01 (executed) / recorded 2016-02-19 — Reel 035651/0157
  • Conveyance: Assignment
  • Assignor: HEWLETT-PACKARD COMPANY
  • Assignee: HP INC.
  • Correspondent: BLAKELY S. PRATT, HP INC.
  • Context: Corporate separation of Hewlett-Packard Company into HP Inc. and Hewlett Packard Enterprise.

Timeline diagram

timeline
    title Ownership of US 5115326
    1990 : Filed by Hewlett Packard Co
    1991 : Inventors assigned to Hewlett-Packard
    1992 : Issued
    2001 : Internal reorganization
    2015 : Assigned to HP Inc

NPE / troll-pattern signals

1. Shell-entity transfer — not present. All recorded assignees are operating companies (Hewlett-Packard Company, HP Inc.).
2. Known asserter in the chain — not present. No known NPEs or patent asserters appear in the assignment chain.
3. Repeat correspondent across the chain — unclear. While John B. Hamlin and Blakely S. Pratt appear as correspondents for Hewlett-Packard entities, there isn't enough information to determine if they are repeat players across multiple unrelated NPE assertion chains tracked on this site.
4. Cascading transfers — not present. There are no multiple consecutive assignments through chained LLCs in a short timeframe.
5. Pre-litigation transfer — not present. No litigation was found involving this patent.
6. Bankruptcy fire-sale — not present. The transfers appear to be part of normal corporate restructuring.
7. Privateering — not present. There is no indication of transfers to an NPE for assertion on behalf of an operating company.
8. Defensive aggregator (anti-NPE) — not present. The chain ends with HP Inc., an operating company.

Verdict

Insufficient data. While the patent is currently owned by an operating company (HP Inc.), there is no evidence to suggest either NPE assertion or defensive aggregation. The transfers are consistent with corporate restructuring.

Prior Art Analysis for U.S. Patent 5,115,326

Based on the patent documentation for US 5,115,326, the following U.S. Patents were cited as prior art by the applicant. This analysis assesses their relevance to the claims of the '326 patent.

---

1. U.S. Patent 4,893,330: "Facsimile Mail System"

• Full Citation: U.S. Patent 4,893,330, issued to R. M. St-Amand, filed on July 29, 1988, and published on January 9, 1990.
• Brief Description: This patent describes a system for sending facsimile messages to subscribers of an electronic mail (E-mail) system. A central "facsimile-mail processing center" receives a fax, digitizes it, and stores it in a database. The sender can then dial into the system and provide the recipient's E-mail address via DTMF (touch-tone) signals. The system retrieves the stored fax and transmits it to the specified E-mail address.
• Potential Anticipation of Claims:
  • Claim 1 & 9 (Routing fax to a network address): This patent is highly relevant. It discloses the core concept of a centralized system receiving a fax and routing it to a network (E-mail) destination. However, the method of specifying the destination address is critically different. The '330 patent uses DTMF tones entered during a phone call after the fax is sent, whereas the '326 patent specifies the address directly on the document itself using a bar code. Therefore, while it teaches the general system architecture, it does not anticipate the specific method of encoding the address on the message, which is a key limitation of claims 1 and 9 of the '326 patent.

---

2. U.S. Patent 4,754,426: "Apparatus for Transmission of Coded Information"

• Full Citation: U.S. Patent 4,754,426, issued to B. T. H. Tashima et al., filed on December 23, 1985, and published on June 28, 1988.
• Brief Description: This patent details a method for transmitting data that includes both image information (like a fax) and coded character data (like ASCII text) in a single transmission. It describes a system where a document can have marks or codes that are read by the transmitting terminal. This coded information can be used for various purposes, including addressing or providing commands.
• Potential Anticipation of Claims:
  • Claim 1, 7, & 9 (Encoding information on the document): This patent discloses the concept of placing machine-readable codes on a document that is being faxed to convey information beyond the image itself. This is a foundational concept for the '326 patent. However, the '426 patent appears to focus on the transmission protocol and the general use of coded data rather than the specific application of using a bar code on a cover sheet to automatically route the entire document image to a specific network e-mail address by a central server. It does not explicitly describe a "fax server" that intercepts the message, decodes the address, and forwards it on a LAN. The '326 patent's claims are specific to this server-based routing workflow.

---

3. U.S. Patent 4,654,724: "Automatic Facsimile Communication System"

• Full Citation: U.S. Patent 4,654,724, issued to M. Kurihara, filed on May 24, 1984, and published on March 31, 1987.
• Brief Description: This patent describes an automatic facsimile system where a transmitting machine can read destination information from a "request card" or "mark sheet." This sheet contains marks (like filled-in circles) that represent a pre-registered destination telephone number. The machine reads the card, looks up the corresponding full phone number from a memory, and automatically dials and sends the subsequent document pages.
• Potential Anticipation of Claims:
  • Claim 1, 7, & 9 (Automatic routing from document information): This reference teaches automatic transmission based on machine-readable information on a special sheet. This is conceptually similar to the '326 patent's use of a bar-coded cover page. However, the '724 patent is focused on automating the dialing of a destination fax machine's telephone number. It does not describe routing a fax image to an E-mail or other computer network address, which is the central innovation claimed in the '326 patent. The destination is another endpoint on the telephone network, not a node on a computer network.

---

4. U.S. Patent 4,837,834: "Facsimile Apparatus with Bar Code Reading Function"

• Full Citation: U.S. Patent 4,837,834, issued to Y. O-Otake, filed on July 14, 1987, and published on June 6, 1989.
• Brief Description: This patent discloses a facsimile machine that incorporates a bar code reader. The bar code reader can scan a bar code that contains a destination telephone number. This allows a user to initiate a fax transmission by simply scanning a bar code instead of manually dialing the number.
• Potential Anticipation of Claims:
  • Claim 1 & 9 (Using bar code for destination): This patent explicitly teaches using a bar code to encode a destination address for a fax. This is a significant element of the '326 patent. However, like the '724 patent, the destination encoded in the bar code is a telephone number for another fax machine. It does not anticipate the novel step of a fax server interpreting a bar code as a computer network (E-mail) address and routing the fax image over that network. The claimed method in '326 operates at a server gateway between the telephone network and a computer network, a different context than the point-to-point fax machine described here.
  • Claim 5 (Orientation detection): This patent does not appear to describe or suggest using an asymmetrical bar code to detect document orientation. Its focus is on automating the dialing process.

Obviousness Analysis of U.S. Patent 5,115,326

This analysis evaluates the claims of U.S. Patent 5,115,326 for obviousness under 35 U.S.C. § 103, considering the state of the art prior to the patent's filing date of June 26, 1990. The analysis is based on the previously identified prior art references: U.S. Patents 4,893,330 (St-Amand), 4,754,426 (Tashima), 4,654,724 (Kurihara), and 4,837,834 (O-Otake).

A person having ordinary skill in the art (PHOSITA) at the time of this invention would have been familiar with computer networking (including LANs and early E-mail systems), facsimile technology, and machine-readable optical codes such as bar codes.

---

Analysis of Independent Claims 1 and 9

Claim 1: A method for a fax server to automatically route a fax message by inspecting a bar-coded destination address on the first page and sending the message to that network address.

Claim 9: A method for a user to send a document from a fax machine to a network recipient by creating and sending a cover page with the recipient's network address encoded in a bar code.

Obviousness Combination: U.S. Patent 4,893,330 (St-Amand) in view of U.S. Patent 4,837,834 (O-Otake).

Rationale:

1. Starting Point (St-Amand '330): The St-Amand patent discloses the foundational system: a central "facsimile-mail processing center" (functionally equivalent to the '326 patent's "fax server") that receives a fax via the telephone network and routes it to a subscriber's E-mail address. This establishes the entire fax-to-E-mail gateway concept. However, St-Amand's method for providing the destination address is inefficient; the user must call in and enter the address using DTMF tones after sending the fax. A PHOSITA would recognize this two-step process as cumbersome, slow, and prone to user error.

2. The Problem to Be Solved: The clear problem with the St-Amand system is the need for a more integrated and user-friendly method of specifying the E-mail destination. The ideal solution would be to provide the address along with the document in a single, unified transmission.

3. The Obvious Solution (O-Otake '834): The O-Otake patent provides a direct and obvious solution to this problem. O-Otake explicitly teaches the use of a bar code, scanned by a facsimile machine, to encode a destination address. While O-Otake specifies encoding a telephone number, the principle of using a bar code to represent a destination address for a fax transmission is clearly taught.

4. Motivation to Combine: A PHOSITA, tasked with improving the St-Amand fax-to-E-mail system, would be motivated by the desire for efficiency and reliability to replace the DTMF-entry step. Looking to the state of the art for fax addressing, they would encounter the O-Otake patent, which demonstrates that bar codes are a known and viable method for this exact purpose. The motivation to combine would be to replace an inefficient input method (DTMF) with a more efficient, integrated one (bar code). Applying O-Otake's bar code addressing method to St-Amand's fax-to-E-mail system would have been a predictable design choice. The substitution of an E-mail address for a telephone number within the bar code would be a mere adaptation of the content being encoded, not an inventive step, as the St-Amand system was already designed to handle E-mail addresses.

Conclusion for Claims 1 and 9: The combination of St-Amand and O-Otake teaches all the elements of claims 1 and 9. It would have been obvious to a PHOSITA to use the bar code addressing method of O-Otake to improve the fax-to-E-mail system of St-Amand, thereby arriving at the claimed invention.

---

Analysis of Independent Claim 7

Claim 7: A method for requesting information via fax using a bar-coded message, which is then interpreted by a fax server that automatically takes action.

Obviousness Combination: The system derived from St-Amand '330 and O-Otake '834, further in view of U.S. Patent 4,754,426 (Tashima) and the general knowledge of automated form processing.

Rationale:

1. Starting Point (St-Amand + O-Otake): The combination above establishes a system where a fax server can receive a fax and intelligently interpret a bar code on it.

2. The Obvious Extension: Once such a system exists, a PHOSITA would consider other potential uses for the bar-coded data channel beyond simple addressing. The Tashima patent teaches that machine-readable codes on a faxed document can be used not just for addressing but also as "commands."

3. Motivation to Combine: The motivation would be automation and efficiency. A "request for information" is a type of command. A PHOSITA would recognize that if the server can already read a bar code, it can be programmed to take different actions based on the content of that bar code. Using the bar code to trigger an automated information-retrieval and response process (like the "bingo card" example in the '326 patent) would be a logical and predictable extension of the technology. This would automate a routine task, reduce manual labor, and provide faster service. The concept of using machine-readable marks on a form to trigger a specific data processing action was already well-established in the art of optical mark recognition (OMR). Applying this concept to the newly-established fax-based bar code reading system would have been an obvious next step.

Conclusion for Claim 7: It would have been obvious to extend the functionality of the fax server (derived from St-Amand and O-Otake) from simply routing messages to processing commands, as suggested by Tashima, to automate information requests.

---

Analysis of Independent Claim 5

Claim 5: A method for determining document orientation by using an asymmetrical bar code and attempting to read it from two opposing directions.

Obviousness Combination: The system derived from St-Amand '330 and O-Otake '834, in view of the general knowledge in the art of bar code scanning technology prior to 1990.

Rationale:

1. Starting Point and Problem: When implementing the bar code reading system of St-Amand and O-Otake, a PHOSITA would immediately confront the foreseeable and common user error of feeding a document into the fax machine upside down. This would cause the bar code scan to fail. Solving this problem would be a necessary step to make the system robust and commercially viable.

2. The Known Solution in the Art: The art of bar code technology prior to 1990 already contained the solution. Many widely used 1D bar code symbologies, such as the UPC, were designed with features to ensure readability regardless of scan direction (bi-directionality). This was often achieved through the use of distinct start and stop characters or other asymmetrical features within the code structure. The UPC, for example, used differing start/stop patterns for the left and right halves of the symbol. Scanning a barcode from both left-to-right and right-to-left to ensure a successful read was a standard technique in scanner design.

3. Motivation to Apply: A PHOSITA, facing the problem of incorrect page orientation, would be motivated to look at how this problem was solved in the field of dedicated bar code scanners. They would find that bi-directional scanning and the use of asymmetrical codes were known methods to ensure scanning robustness. Applying this known technique from the field of bar code reading to the context of a fax server application would be an obvious and logical step. The motivation is clear: to increase the reliability and user-friendliness of the system by automatically correcting a common user error. Once the orientation is determined from the successful scan direction, the final step of electronically reorienting the digital image of the fax is a trivial data manipulation task for a computer system.

Conclusion for Claim 5: The method of using an asymmetrical bar code and bi-directional scanning to determine orientation was a known technique in the broader art of bar code scanning. It would have been obvious to a PHOSITA to apply this known technique to solve the foreseeable problem of upside-down documents in the context of a fax-to-network server.

Analysis for U.S. Patent 5,115,326

Based on a review of USPTO records and patent law as of April 29, 2026, the following details pertain to the term and application history of U.S. Patent 5,115,326.

Patent Term Adjustments (PTA) and Extensions (PTE)

• Patent Term Adjustment (PTA): There are no Patent Term Adjustments for this patent. The PTA system was established under the American Inventors Protection Act of 1999 to compensate for certain USPTO processing delays for applications filed on or after May 29, 2000. As this patent's application was filed in 1990, it does not qualify for PTA.
• Patent Term Extension (PTE): There are no Patent Term Extensions for this patent. PTE under 35 U.S.C. § 156 is typically granted for delays caused by regulatory review, such as by the Food and Drug Administration (FDA), and is not applicable to this technology.

Application Continuity

A search of the USPTO's continuity data for the application leading to this patent, US07/543,998, shows no parent or child applications. This means:

• No Continuation or Divisional Applications: This patent is not a continuation or divisional of a prior U.S. application, nor were any continuation or divisional applications filed that claim priority to this patent's application. It is a standalone utility application.

Patent Family and Related Applications

The patent claims priority to its U.S. filing on June 26, 1990. The extended (INPADOC) patent family includes several foreign counterparts, indicating that the applicant sought protection for this invention in multiple countries. The known members of the patent family are:

• United States: US5115326A (This patent)
  • Application Number: US07/543,998
  • Filed: June 26, 1990
• Europe: EP0465011A2
  • Application Number: EP91305122A
  • Filed: June 6, 1991
• Germany: DE69122991T2
  • This is the German validation of the European patent.
• Japan: JPH05199388A (Also published as JP3181995A)
  • Application Number: JP15580691A
  • Filed: June 26, 1991

Projected Expiration Date

The expiration date for this patent must be calculated according to the laws established by the 1994 Uruguay Round Agreements Act (URAA). For patents that were in force on June 8, 1995, the patent term is the longer of:

1. 17 years from the issue date.
2. 20 years from the earliest effective filing date.

Let's calculate both for US 5,115,326:

1. Issue Date: May 19, 1992
   • May 19, 1992 + 17 years = May 19, 2009
2. Filing Date: June 26, 1990
   • June 26, 1990 + 20 years = June 26, 2010

The longer of these two terms is the one that applies. Therefore, the projected expiration date was June 26, 2010.

Conclusion: U.S. Patent 5,115,326 officially expired on June 26, 2010. All maintenance fees were paid throughout its term, and the patent remained in force for its full, legally-defined lifetime.

Defensive Disclosure Document

Publication Date: April 29, 2026
Reference ID: DPD-2026-5115326
Title: Derivative Methods and Systems for Routing and Processing Image-Based Messages via Embedded Machine-Readable Metadata
Status: Publicly Disclosed

This document describes variations, extensions, and novel applications of the core methods disclosed in U.S. Patent 5,115,326, with the intent to place these concepts into the public domain and establish them as prior art.

---

Part 1: Derivatives of Fax-to-Network Routing via Embedded Code (Claims 1 & 9)

1.1. Material & Component Substitution

1.1.1. Digital Watermark Steganography for Routing

• Enabling Description: A method where the network destination address is not visibly encoded but is embedded as a robust, low-frequency digital watermark within the luminance channel of the first page's scanned image. The encoding process utilizes a Discrete Cosine Transform (DCT) on 8x8 pixel blocks of the cover page image. The ASCII characters of the email address are converted to a binary string, which is then embedded into the low-to-mid frequency DCT coefficients of selected blocks. The receiving fax server performs a corresponding DCT analysis on the first page, extracts the binary string from the coefficients, reconstructs the address, and routes the message. This method is resilient to scaling, rotation, and lossy compression artifacts common in fax transmission.
• Diagram:

  sequenceDiagram
      participant Sender
      participant FaxServer as Fax Server (Gateway)
      participant Recipient
  
      Sender->>FaxServer: Transmits Fax (Page 1 with Watermark)
      activate FaxServer
      FaxServer->>FaxServer: Scan Page 1 Image Data
      FaxServer->>FaxServer: Perform DCT on Image Blocks
      FaxServer->>FaxServer: Extract Binary String from Coefficients
      FaxServer->>FaxServer: Reconstruct Network Address (e.g., email)
      FaxServer->>Recipient: Route Fax Image to Network Address
      deactivate FaxServer
  

1.1.2. Embedded RFID in Cover Sheet

• Enabling Description: The cover sheet is manufactured with a passive, ultra-thin RFID tag (e.g., operating at 13.56 MHz, compliant with ISO/IEC 14443) embedded within the paper substrate. The destination network address is written to the tag's memory by a desktop RFID writer prior to sending. The document feeder of the receiving gateway is equipped with an RFID interrogator antenna. As the cover sheet is fed, the interrogator powers the tag and reads the stored address. This address is passed to the routing daemon, which then processes and forwards the subsequent scanned image data. This decouples routing information from the optical image, making it immune to smudges, poor print quality, or OCR errors.
• Diagram:

  graph TD
      A[Sender places document with RFID-embedded cover sheet in fax] --> B{Fax Gateway Paper Feeder};
      B -- Feeds Paper --> C[RFID Interrogator];
      C -- Powers & Reads Tag --> D[RFID Tag Memory];
      D -- "user@network.com" --> C;
      C -- Address Data --> E[Routing Daemon];
      B -- Scans Image --> E;
      E -- Packages and Sends --> F[Recipient on Network];
  

1.1.3. 2D Matricial Code for Enhanced Routing Data

• Enabling Description: Instead of a 1D bar code, a 2D matricial code (e.g., QR Code or Data Matrix) is used on the cover page. This allows for encoding a structured data object, such as a JSON payload. The payload can include multiple recipients ("to": ["a@net.com", "b@net.com"]), a carbon copy list ("cc": [...]), a priority level ("priority": "high"), and a UUID for tracking ("uuid": "..."). The receiving server uses a 2D code library (e.g., ZXing) to scan the first page image, decode the matrix, parse the JSON object, and execute the complex routing logic defined therein.
• Diagram:

  classDiagram
    class EncodedDataObject {
      +to: string[]
      +cc: string[]
      +priority: string
      +uuid: string
      +subject: string
    }
    class FaxGateway {
      +receiveFax(image)
      -decodeQRCode(image) EncodedDataObject
      -parseRoutingJSON(data)
      -routeMessage(payload, image)
    }
    EncodedDataObject <.. FaxGateway : decodes to
  

1.2. Operational Parameter Expansion

1.2.1. Industrial Routing via Etched Codes on Metal Plates

• Enabling Description: A method for routing quality control reports in an industrial foundry. Reports are etched or laser-marked as 2D Data Matrix codes directly onto thin metal plates accompanying a batch of materials. The "fax" is an imaging station that uses a structured light scanner or a laser profilometer to read the code, which is resistant to extreme heat (up to 500°C) and chemical exposure. The code contains the batch ID, material type, and the network address of the quality control database server. The imaging station transmits the image of the plate and the decoded routing data to a central server for archival.
• Diagram:

  flowchart LR
      subgraph Foundry Floor
          A[Material Batch] -- Accompanied by --> B(Metal Plate with Etched Code);
      end
      subgraph Imaging Station
          C{Structured Light Scanner} -- Reads --> B;
          C -- Decoded Data & Image --> D[Gateway Computer];
      end
      D -- Transmits to --> E((QC Database Server));
  

1.3. Cross-Domain Application

1.3.1. AgTech: Field Sample Routing

• Enabling Description: In agricultural technology, soil and plant tissue samples are collected in the field. Each sample bag is affixed with a durable, weatherproof label containing a QR code. The code stores GPS coordinates, timestamp, sample type, and the ID for the target analysis workflow (e.g., 'nitrate_analysis_protocol_3'). At a mobile or central lab, the bag's label is scanned. The scanner captures an image of the label and transmits it to a LIMS (Laboratory Information Management System). The LIMS server decodes the QR code and uses the workflow ID to automatically assign the required tests and route the results to the correct farmer's account on the crop management platform.
• Diagram:

  sequenceDiagram
      participant Farmer
      participant FieldScanner as Field Lab Scanner
      participant LIMS_Server as LIMS Server
      participant CropPlatform as Crop Management Platform
  
      Farmer->>FieldScanner: Submits Sample Bag with QR Code Label
      activate FieldScanner
      FieldScanner->>LIMS_Server: Transmits image of label
      deactivate FieldScanner
      activate LIMS_Server
      LIMS_Server->>LIMS_Server: Decode QR (GPS, Timestamp, Workflow ID)
      LIMS_Server->>CropPlatform: Route analysis results based on ID
      activate CropPlatform
      CropPlatform->>Farmer: Display results on dashboard
      deactivate CropPlatform
      deactivate LIMS_Server
  

1.4. Integration with Emerging Tech

1.4.1. AI-Driven Dynamic Routing & Content Analysis

• Enabling Description: The bar code on the cover sheet contains a basic recipient identifier (e.g., a corporate user ID). The receiving server decodes this ID and queries a real-time presence service (e.g., Microsoft Graph API) to check the recipient's status. Concurrently, it performs OCR and Natural Language Processing (NLP) on the fax content to determine its topic and urgency. An AI decision engine combines these inputs: if the content is an urgent legal summons and the recipient is on vacation, the engine reroutes the fax to the general counsel's office and sends an SMS alert. The routing rules are not static but are learned by a machine learning model based on historical routing decisions and outcomes.
• Diagram:

  graph TD
      A[Fax Received] --> B{Decode Barcode for User ID};
      A --> C{OCR & NLP on Fax Content};
      B --> D{Query Presence API};
      C --> E[Topic & Urgency];
      D --> F[User Status];
      subgraph AI_DecisionEngine as AI Decision Engine
          G((Combine: ID, Topic, Status));
      end
      E & F --> G;
      G --> H{Apply Learned Routing Policy};
      H --> I[Route to Optimal Destination];
  

1.4.2. Blockchain-Verified Immutable Transmission

• Enabling Description: A method for transmitting legally binding documents. The sender first calculates a SHA-256 hash of the document image. They initiate a transaction on a private blockchain (e.g., Hyperledger Fabric) containing this hash, the recipient's public key, and a timestamp. The transaction ID is encoded into a QR code on the cover sheet. The receiver's gateway scans the QR code, queries the blockchain with the transaction ID to retrieve the original hash and recipient key. It re-calculates the hash of the received image and verifies it matches the one on the blockchain. If valid, it encrypts the document with the recipient's key before delivery, creating a tamper-proof, non-repudiable audit trail.
• Diagram:

  sequenceDiagram
      participant Sender
      participant Blockchain
      participant FaxGateway
      participant Recipient
  
      Sender->>Sender: Hash(Document) -> H1
      Sender->>Blockchain: Store {H1, Recipient_PubKey} -> TxID
      Sender->>FaxGateway: Send Fax with QR(TxID)
      activate FaxGateway
      FaxGateway->>FaxGateway: Decode QR -> TxID
      FaxGateway->>Blockchain: Query TxID -> {H1, Recipient_PubKey}
      FaxGateway->>FaxGateway: Hash(Received Image) -> H2
      alt Hashes Match (H1 == H2)
          FaxGateway->>FaxGateway: Encrypt(Image, Recipient_PubKey)
          FaxGateway->>Recipient: Deliver Encrypted Document
      else Hashes Mismatch
          FaxGateway->>Sender: Send Tamper Alert
      end
      deactivate FaxGateway
  

1.5. The "Inverse" or Failure Mode

1.5.1. Redacted Safe Mode Routing

• Enabling Description: A system for environments handling PII, such as healthcare or finance. If the routing bar code is unreadable or fails checksum validation, the server assumes a high risk of mis-delivery. It automatically enters a "safe mode" where it performs full-page OCR and applies a regex-based redaction engine to identify and black-out patterns matching social security numbers, credit card numbers, patient IDs, etc. Only this redacted version of the fax is then forwarded to a human administrator in a secure "unroutable items" queue for manual processing, thus preventing accidental data exposure.
• Diagram:

  stateDiagram-v2
      [*] --> Receiving
      Receiving --> Decoding: Fax Arrives
      Decoding --> Routing: Barcode OK
      Routing --> [*]
      Decoding --> RedactionEngine: Barcode Read Failure
      RedactionEngine --> AdminQueue: Perform OCR & Redact PII
      AdminQueue --> [*]: Manual Review
  

---

Part 2: Derivatives of Document Orientation Detection (Claim 5)

2.1. Material & Component Substitution

2.1.1. Asymmetrical Digital Watermark

• Enabling Description: An invisible digital watermark is embedded in the document image with a mathematically asymmetrical pattern. The decoding algorithm functions by attempting to correlate a key against the image data. The key itself is asymmetrical, meaning the correlation will only succeed with a high confidence score when the image is in its intended 0-degree orientation. The server attempts the correlation at 0, 90, 180, and 270 degrees. The orientation that produces the highest correlation score is determined to be the correct one, and the image is rotated accordingly.
• Diagram:

  flowchart TD
      A[Scan Image] --> B{Attempt Decode at 0°};
      B -- Fail --> C{Attempt Decode at 90°};
      C -- Fail --> D{Attempt Decode at 180°};
      D -- Fail --> E{Attempt Decode at 270°};
      B -- Success --> F[Set Orientation=0°];
      C -- Success --> G[Set Orientation=90°];
      D -- Success --> H[Set Orientation=180°];
      E -- Success --> I[Set Orientation=270°];
      F & G & H & I --> J[Rotate Image to Correct Orientation];
  

2.2. Integration with Emerging Tech

2.2.1. Unsupervised ML Model for Orientation

• Enabling Description: A method that requires no special markings. A Convolutional Neural Network (CNN) is pre-trained on a large, unlabeled corpus of typical business documents. The model learns the general features of document layouts, such as the common locations of headers, footers, and the predominant direction of text flow. When a new fax is received, the image is passed through the CNN, which outputs a vector of probabilities for each of the four cardinal orientations (0, 90, 180, 270 degrees). The server rotates the image to the orientation with the highest probability before routing. This system can correctly orient legacy documents that lack any special codes.
• Diagram:

  graph LR
      A[Scanned Fax Image] --> B(CNN Model);
      B --> C["Output:
      P(0°)=0.95
      P(90°)=0.02
      P(180°)=0.02
      P(270°)=0.01"];
      C --> D{Select Max Probability};
      D -- "0°" --> E[Keep Original Orientation];
  

---

Part 3: Combination with Open-Source Standards

3.1. Integration with RFC 2301 (Internet Fax) and JSON Schema

• Enabling Description: A system where the routing bar code on the fax cover page contains a Base64-encoded JSON object. The schema for this JSON object is published as an open standard (e.g., at schema.org/FaxRouting). The receiving gateway, compliant with RFC 2301 for creating email-based fax messages, decodes the barcode and the JSON. It then uses the key-value pairs from the JSON (e.g., to, subject, priority) to programmatically populate the corresponding MIME headers of the outgoing email message, ensuring interoperability between different vendors' fax server implementations that adhere to the public schema.

3.2. Integration with CUPS (Common UNIX Printing System) and Zint

• Enabling Description: A CUPS print filter is created that intercepts print jobs directed to a "fax" printer. The filter script uses the open-source Zint barcode generation library to create a QR code containing the job's metadata (requesting user, destination number/email, timestamp). The script then uses ImageMagick to prepend the generated QR code image as a new first page to the original print job's PostScript or PDF file. The modified job is then passed to the physical fax modem backend. This allows any application printing through a standard CUPS server to generate compliant, routable faxes automatically.

3.3. Integration with ActivityPub Protocol for Decentralized Routing

• Enabling Description: The bar code on the document contains a decentralized identifier compliant with the ActivityPub protocol (e.g., a user handle like @username@example.com). The receiving gateway acts as a federated server instance. Upon receiving and decoding the address, it OCRs the fax content to text. It then constructs a Create activity in ActivityPub format, with the OCR'd text as the content and the fax image as an attachment. This activity is posted to the outbox of a system actor, which federates the message to the destination user's instance. This allows faxes to be delivered directly and securely into decentralized social media or messaging platforms.