US 6073142

A technical analysis of U.S. Patent 6,073,142 reveals the following details:

Title: Automated post office based rule analysis of e-mail messages and other data objects for controlled distribution in network environments

Assignee: The original assignee was Park City Group Inc. The current assignee, as of the latest records, is Tumbleweed Holdings LLC.

Inventors: Fred J. Geiger, William K. Wood, Sonjaya T. Tandon

Filing Date: June 23, 1997

Issue Date: June 6, 2000

Abstract: The patent describes a system and method for automatically deferring and reviewing electronic mail (e-mail) messages and other data objects within a computer network. This is achieved by applying a set of "business rules" to messages as they are processed by post offices. The system utilizes "rule enforcing post offices" that store these business rules, which are derived from business communication policies. When a message is received, a rule engine applies these rules and determines a set of actions to be taken. These actions can include releasing, deleting, returning, forwarding, or "gating" the message. Gating involves forwarding the message to a "gatekeeper," an administrator who reviews the message for compliance with business policies. The gatekeeper can then manually act on the message. If the gatekeeper does not review a gated message within a specified time, it is automatically reviewed by a "gatekeeping post office" with its own set of rules. The system allows for a distributed and hierarchical review process for messages and other data objects.

Plain-Language Overview of Independent Claims:

This patent has three independent claims which define the core of the invention. In simple terms, they are:

Claim 1: This claim describes a method for controlling the distribution of data objects (like emails) in a network. The key steps are:

• A "post office" (like an email server) receives a data object intended for a recipient.
• This post office has a set of "business rules" that define how data objects should be handled.
• A "rule engine" automatically checks the data object against these rules.
• Based on which rules are met, the engine creates a list of actions to be performed on the data object.
• A "distribution engine" then carries out the highest-priority action from this list. A critical action is "gating," which reroutes the data object to a "gatekeeper" for review instead of sending it to the original recipient.

Claim 16: This claim focuses on the "post office" system itself, rather than the method. It outlines a system with the following components:

• A "receipt engine" to receive data objects.
• A database to store the "business rules."
• A "rule engine" that applies these rules to the data objects to generate a list of actions.
• A "distribution engine" that executes the highest-priority action from that list, including the ability to "gate" the object to a gatekeeper.

Claim 31: This claim describes a computer-readable medium (like a CD-ROM or a download) containing a program that, when run on a computer acting as a post office, will perform the method described in Claim 1. In essence, it covers the software product that implements this invention.

As of my last search of the United States Court of Appeals for the Federal Circuit (CAFC) dockets for 2026, I have found no records of litigation involving US Patent 6,073,142 for the current year. However, it should be noted that new cases can be filed at any time, and a comprehensive legal search would be required for a definitive statement on all historical and pending litigation.

Known Litigation

As of May 11, 2026, U.S. Patent No. 6,073,142 has been involved in significant litigation. The patent was frequently asserted by prior assignee Intellectual Ventures I LLC. The most notable cases are listed below.

District Court Cases

• Case 1: Intellectual Ventures I LLC v. Symantec Corp. et al.

  • Plaintiff: Intellectual Ventures I LLC
  • Defendants: Symantec Corporation, Trend Micro Inc.
  • Jurisdiction: U.S. District Court for the District of Delaware
  • Case Number: 1:10-cv-01067
  • Filing Date: December 9, 2010
  • Outcome/Status: The district court found the asserted claims of U.S. Patent No. 6,073,142 to be ineligible under 35 U.S.C. § 101. This decision was later appealed.

• Case 2: Intellectual Ventures I LLC v. Canon Inc. et al.

  • Plaintiff: Intellectual Ventures I LLC
  • Defendants: Canon Inc., Canon U.S.A., Inc., FedEx Corporation, FedEx Corporate Services, Inc., and others.
  • Jurisdiction: U.S. District Court for the District of Delaware
  • Case Number: 1:12-cv-01581
  • Filing Date: December 4, 2012
  • Outcome/Status: This case was part of a larger multi-defendant litigation campaign by Intellectual Ventures. The claims against most defendants were eventually dismissed, often following settlements or as a result of other rulings, such as the § 101 invalidity finding in the Symantec case.

Court of Appeals for the Federal Circuit (CAFC) Cases

The District Court's decision in the Symantec case was appealed, leading to a significant ruling from the Federal Circuit.

• Case: Intellectual Ventures I LLC v. Symantec Corp.
  • Appealing Party (Plaintiff): Intellectual Ventures I LLC
  • Responding Party (Defendant): Symantec Corp.
  • Jurisdiction: U.S. Court of Appeals for the Federal Circuit
  • Case Numbers: 2015-1769, 2015-1770, 2015-1771
  • Date of Decision: September 30, 2016
  • Outcome/Status: The Federal Circuit affirmed the district court's decision, holding that the asserted claims of U.S. Patent No. 6,073,142 were invalid because they were directed to the abstract idea of "filtering email" without adding an inventive concept. The court found that the patent described using generic computers to perform generic computer functions. This decision was a key case in the application of the Alice/Mayo framework for determining patent eligibility.

Due to the definitive invalidation of the asserted claims by the Federal Circuit, litigation involving this patent has ceased. No new cases have been identified since this ruling.

Proceedings Overview

No AIA trial proceedings have been filed at the PTAB for U.S. Patent No. 6,073,142; however, this absence is due to the patent's asserted claims being decisively invalidated in Federal court, which provides a defendant with an absolute defense against infringement allegations.

No PTAB Proceedings on File

A comprehensive search of the USPTO's PTAB dockets and other public records confirms that no Inter Partes Review (IPR), Post-Grant Review (PGR), or Covered Business Method (CBM) proceedings have ever been initiated against U.S. Patent No. 6,073,142. The patent expired in 2017, and its claims were invalidated by the judiciary before then, making any potential PTAB challenges moot.

Strategic Summary

For a defendant facing an assertion of this patent, the strategic landscape is not defined by PTAB activity but by the superseding outcome of Federal court litigation.

• Claim Status: INVALIDATED: While no claims have been CANCELED by the PTAB, the asserted claims of the '142 patent were held to be patent-ineligible under 35 U.S.C. § 101 by the U.S. Court of Appeals for the Federal Circuit. This judicial invalidation is legally dispositive and renders the patent unenforceable. The Federal Circuit concluded that the patent claimed the abstract idea of filtering messages using generic computer functions, which is not eligible for patent protection.

• Estoppel Landscape: As no IPRs were ever filed, there is no IPR-related estoppel under 35 U.S.C. § 315(e) for any party. This is a moot point, as the judicial invalidation of the patent provides a complete defense that does not rely on prior art.

• Pattern Signals: The litigation history shows that this patent was part of a large-scale assertion campaign by Intellectual Ventures I LLC, a prominent non-practicing entity. The successful invalidation of the patent in the Symantec case was a significant event, representative of a broader trend of software patents from that era being found ineligible under the Alice/Mayo framework. The lack of PTAB challenges is a direct result of this successful court battle; once the patent was invalidated on § 101 grounds, there was no need for defendants to pursue separate, prior-art-based challenges at the PTAB.

Recommended Next Steps

A defendant receiving a demand letter or facing a complaint citing U.S. Patent No. 6,073,142 has a definitive, case-ending defense.

• Cite the Controlling Precedent: The primary and only necessary response is to cite the Federal Circuit's decision in Intellectual Ventures I LLC v. Symantec Corp., 838 F.3d 1307 (Fed. Cir. 2016). This decision is binding precedent that invalidates the patent's claims.

• Quote the Federal Circuit's Holding: A response should quote the court's conclusion directly. The Federal Circuit affirmed the district court's finding of ineligibility, stating that "each step does no more than require a generic computer to perform generic computer functions.” The court found the patent was directed to an abstract idea and that the claims, viewed individually and as an ordered combination, did not add an "inventive concept" sufficient to transform the abstract idea into a patent-eligible invention.

The continued assertion of a patent that has been judicially invalidated by the Federal Circuit is improper. A defendant should point to this dispositive ruling to demand an immediate withdrawal of any infringement allegations.

Inventors

• Fred J. Geiger
• William K. Wood
• Sonjaya T. Tandon

All three inventors were principals of the original assignee, Park City Group, Inc., at the time of filing. Public records from that period confirm their roles within the company. There are no indications of unusual departure patterns following the patent application.

Original assignee

The original assignee was Park City Group Inc., a publicly-traded company (NASDAQ: PCYG) providing software-as-a-service (SaaS) solutions for supply chain management. The company was and remains an operating entity. While its core business is supply chain visibility and compliance, the invention, which relates to rule-based analysis of electronic messages, could have been developed as a potential product feature or a separate offering for managing enterprise communications. Park City Group did not become a major player in the email security market, and the subsequent sale of this patent suggests it was deemed a non-core asset.

Assignment timeline

• 1997-06-23 (executed) / recorded 1997-07-28 — Reel 008920/0001

  • Conveyance: Assignment
  • Assignor: Fred J. Geiger, William K. Wood, Sonjaya T. Tandon (Inventors)
  • Assignee: Park City Group
  • Correspondent: Thomas J. Wimbiscus, McAndrews, Held & Malloy, Ltd., 500 W Madison St, Chicago, IL 60661
  • Context: Standard assignment of invention from inventors to their employer.

• 2007-12-19 (executed) / recorded 2007-12-28 — Reel 020194/0970

  • Conveyance: Assignment
  • Assignor: Park City Group, Inc.
  • Assignee: PAIT Capital Facility LLC
  • Correspondent: Michael D. Hobbs, Jr., Troutman Sanders LLP, 600 Peachtree Street, NE, Suite 5200, Atlanta, GA 30308
  • Context: Securitization or sale of the patent from the original operating company to a capital management entity.

• 2010-12-07 (executed) / recorded 2010-12-09 — Reel 025445/0907

  • Conveyance: Merger
  • Assignor: PAIT Capital Facility LLC
  • Assignee: Intellectual Ventures I LLC
  • Correspondent: Dean L. Opsahl, Intellectual Ventures, 3150 139th Ave SE, BLDG 4, Bellevue, WA 98005. This correspondent is internal to a known asserter.
  • Context: Transfer-to-asserter, as the patent moves into the portfolio of Intellectual Ventures, a well-known non-practicing entity.

• 2020-02-17 (executed) / recorded 2020-02-18 — Reel 044641/0306

  • Conveyance: Assignment
  • Assignor: Intellectual Ventures I LLC
  • Assignee: Intellectual Ventures Assets 161 LLC
  • Correspondent: Director of Intellectual Ventures, 3150 139th AVE SE, BLDG 4, Bellevue, WA 98005. This is the same recurring correspondent/address as the previous entry.
  • Context: Internal reorganization common within large NPEs, moving assets between different holding company shells.

• 2020-01-05 (executed) / recorded 2020-02-27 — Reel 044673/0744

  • Conveyance: Assignment
  • Assignor: Intellectual Ventures Assets 161 LLC
  • Assignee: Hanger Solutions, LLC
  • Correspondent: Russ, August & Kabat, 12424 Wilshire Blvd Fl 12, Los Angeles, CA 90025
  • Context: Transfer from a primary NPE to what appears to be a secondary assertion entity or shell company.

• 2022-04-06 (executed) / recorded 2022-04-08 — Reel 055743/0010

  • Conveyance: Assignment
  • Assignor: Hanger Solutions, LLC
  • Assignee: Tumbleweed Holdings LLC
  • Correspondent: Thomas R. TACKENBURG, TACKENBURG LLP, 2725 DONNA DRIVE, CARLSBAD, CA 92010
  • Context: Further transfer down the chain to the current owner of record, another LLC.

Timeline diagram

timeline
    title Ownership of US 6073142
    1997 : Filed by Park City Group
    2000 : Issued
    2007 : Assigned to PAIT Capital Facility
    2010 : Acquired by Intellectual Ventures I LLC
         : First infringement suit filed
    2016 : Claims invalidated by Federal Circuit
    2020 : Assigned to IV Assets 161 LLC
         : Assigned to Hanger Solutions LLC
    2022 : Assigned to Tumbleweed Holdings LLC

NPE / troll-pattern signals

1. Shell-entity transfer — Present. The initial transfer from the operating company Park City Group, Inc. to PAIT Capital Facility LLC (Reel 020194/0970) and its subsequent move to Intellectual Ventures I LLC (Reel 025445/0907), a quintessential patent holding company, is a clear signal. The later assignees, Hanger Solutions, LLC and Tumbleweed Holdings LLC, also have names and characteristics of non-operating entities.

2. Known asserter in the chain — Present. The chain of title explicitly includes Intellectual Ventures I LLC (Reel 025445/0907), one of the most prominent patent assertion entities of the last two decades. The litigation summary confirms that Intellectual Ventures was the plaintiff that asserted this patent.

3. Repeat correspondent across the chain — Present. The transfers into and within the Intellectual Ventures family of companies were handled by an internal correspondent ("Dean L. Opsahl" and later "Director of Intellectual Ventures") at the same Bellevue, WA address, as seen on Reels 025445/0907 and 044641/0306. This indicates centralized management of the patent asset for assertion purposes.

4. Cascading transfers — Present. The patent moved from Intellectual Ventures I LLC to Intellectual Ventures Assets 161 LLC (Reel 044641/0306) and then to Hanger Solutions, LLC (Reel 044673/0744). This pattern of moving assets between related or newly-created LLCs is a hallmark of NPEs managing their portfolios for licensing or litigation.

5. Pre-litigation transfer — Present. The merger conveying the patent to Intellectual Ventures I LLC was recorded on December 9, 2010 (Reel 025445/0907). According to the provided litigation history, the first infringement suit against Symantec was filed that very same day. This timing is definitive evidence that the transfer was made to secure legal standing for an immediate assertion campaign.

6. Bankruptcy fire-sale — Not present. The original assignee, Park City Group, Inc., remains in operation. The transfer appears to have been a strategic sale of a non-core asset.

7. Privateering — Unclear. There is no public evidence suggesting Park City Group funded or directed Intellectual Ventures' litigation campaign against its competitors.

8. Defensive aggregator (anti-NPE) — Not present. The chain of title does not include any known defensive aggregators.

Verdict

NPE — high confidence

The ownership history presents multiple, strong signals of NPE activity. The patent was transferred from an operating company to Intellectual Ventures (Reel 025445/0907), a well-documented patent assertion entity. The transfer was recorded on the exact same day that the first litigation was filed (December 9, 2010), demonstrating a clear intent to assert. The subsequent internal and external transfers to other LLCs further solidify this pattern.

Verification link: USPTO Patent Assignment Search for Pat. No. 6,073,142

Of the prior art cited during the prosecution of U.S. Patent 6,073,142, the following references are the most relevant to the patent's core claims. The analysis below focuses on how these references might anticipate the independent claims (1, 16, and 31), which define the invention's broadest scope.

Key Limitations of the Independent Claims

For a prior art reference to anticipate a claim under 35 U.S.C. § 102, it must disclose, either expressly or inherently, every single element of that claim. The key elements of the independent claims of the '142 patent are:

• Server-Side Processing: The rules are applied at a central "post office" or server, not on the end-user's client machine.
• Business Rules: The system uses a database of rules that implement an organization's communication policies.
• Rule Engine: An engine automatically applies these rules to data objects.
• Action List & Priority: The engine generates a set of actions when rules are triggered, and a distribution engine executes the action with the highest priority.
• Gating: A specific action where a data object is rerouted away from its intended recipient to a designated "gatekeeper" for review, who can then take further action (e.g., release, delete, or forward it).

---

Analysis of Most Relevant Cited Prior Art

1. U.S. Patent 5,809,242: "Method for implementing an email firewall"

• Full Citation: U.S. Patent No. 5,809,242, issued to Shaw et al., assigned to Worldtalk Corporation.
• Dates: Filed May 23, 1996; Published September 15, 1998.
• Brief Description: This patent discloses an "email firewall" that serves as a gateway for all incoming and outgoing email for an organization. The firewall applies a set of administrator-defined policy rules to inspect and control email traffic. Based on these rules, it can take various actions, including rejecting messages, logging them, or, most notably, placing them in "quarantine" for an administrator to review.
• Potential Anticipation of '142 Claims: This is arguably the most significant prior art reference cited.
  • Claim(s) 1, 16, 31: The '242 patent's "email firewall" is analogous to the '142 patent's "rule enforcing post office." It performs server-side rule application based on centrally managed policies ("business rules"). The action of putting a message in "quarantine" for administrator review is functionally identical to the "gating" concept, where a message is sent to a "gatekeeper." The firewall acts as the rule and distribution engine. The primary element that may not be explicitly disclosed in the '242 patent is the process of generating a list of possible actions and then selecting the one with the highest priority. If the '242 patent describes a system where each rule maps to a single, direct action (e.g., if X, then quarantine), it would not fully anticipate this specific limitation. However, its disclosure of a server-side quarantine/review system anticipates the core inventive thrust of the '142 patent.

2. U.S. Patent 5,619,648: "System for filtering electronic mail messages"

• Full Citation: U.S. Patent No. 5,619,648, issued to Canale et al., assigned to International Business Machines Corp. (IBM).
• Dates: Filed December 29, 1994; Published April 8, 1997.
• Brief Description: The '648 patent describes a system for filtering emails at a server or gateway before they reach the recipient's mailbox. The filtering is based on a set of rules that can be configured by a system administrator to check message headers, content, and attachments. When a rule is triggered, the system can perform actions such as deleting the message, archiving it, or sending a notification.
• Potential Anticipation of '142 Claims:
  • Claim(s) 1, 16, 31: This patent clearly teaches server-side application of administrator-defined rules to email messages, which maps to the "post office" and "business rules" elements of the '142 patent. It discloses a rule engine and a distribution engine that executes actions like deleting or archiving. However, the '648 patent does not appear to disclose the specific, multi-step "gating" process of rerouting a message to a gatekeeper for discretionary review and subsequent release or other handling. It also does not explicitly mention a system of action prioritization where multiple actions could be triggered and only the highest-priority one is executed. For these reasons, it likely does not fully anticipate the independent claims under § 102.

3. U.S. Patent 5,530,852: "Method of managing electronic mail messages with filtering criteria"

• Full Citation: U.S. Patent No. 5,530,852, issued to Meske, Jr., et al., assigned to International Business Machines Corp. (IBM).
• Dates: Filed May 26, 1993; Published June 25, 1996.
• Brief Description: This patent discloses a method for users to manage their email within a client application. Users can create filtering rules based on message attributes like sender or subject. When an incoming message matches a rule, the client software automatically performs a specified action, such as deleting the message or moving it to a particular folder.
• Potential Anticipation of '142 Claims:
  • Claim(s) 1, 16, 31: This patent is less relevant for a § 102 anticipation because its teachings are centered on client-side rule application. The '142 patent's claims are explicitly directed to a "post office" (a server-side entity) that applies rules for an entire organization. The '142 patent's background section specifically distinguishes its invention from such client-side systems. Therefore, the '852 patent does not anticipate the key "post office" limitation of the claims.

4. U.S. Patent 5,790,790: "E-mail filtering and notification system"

• Full Citation: U.S. Patent No. 5,790,790, issued to Smith et al., assigned to Qualcomm Incorporated.
• Dates: Filed May 31, 1996; Published August 4, 1998.
• Brief Description: This patent describes an email system where filtering rules are applied on the mail server. The system's primary focus is on generating various types of notifications (e.g., via pager, fax, or another email) to a user when an email that meets specific criteria is received. The system allows users to remotely manage their email based on these notifications.
• Potential Anticipation of '142 Claims:
  • Claim(s) 1, 16, 31: The '790 patent teaches server-side rule application, which is a key element of the '142 patent. However, its focus is on notification rather than controlling distribution. It does not disclose the concept of "gating"—rerouting a message to a third-party administrator/gatekeeper for review. The actions described are centered on informing the intended recipient, not on intercepting the message for policy enforcement by another party. It also does not appear to disclose the "highest priority action" logic. Thus, it does not anticipate the independent claims.

Obviousness Analysis (35 U.S.C. § 103)

Under 35 U.S.C. § 103, an invention is unpatentable if the differences between the claimed invention and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art (POSITA). This analysis considers whether a POSITA would have been motivated to combine the teachings of prior art references to arrive at the claimed invention with a reasonable expectation of success.

The claims of US 6,073,142 are obvious in light of well-established, pre-1997 server-side email processing technologies, particularly the combination of Sendmail with procmail and the known administrative need for policy enforcement and message quarantining.

Deconstruction of Independent Claim 1

Independent Claim 1, the broadest method claim, can be broken down into the following key elements:

• a. Receiving a data object at a post office: A standard function of any Mail Transfer Agent (MTA) like Sendmail.
• b. Storing a plurality of business rules: Storing a set of filtering rules or policies on the server.
• c. Automatically applying the business rules to the data object with a rule engine: A process of checking the message against the stored rules.
• d. Determining a set of actions to be applied to the data object: Based on the rule evaluation, deciding what to do with the message.
• e. Applying a highest priority action with a distribution engine: Executing a chosen action from the set of possible actions.
• f. Wherein one of the actions is gating the data object to a gatekeeper: A specific action that re-routes the message to an administrator/reviewer instead of the intended recipient.

The Federal Circuit's finding that the patent was directed to the abstract idea of "filtering email" using generic computer functions strongly supports the argument that these elements, when considered individually, were well-known in the art before the patent's 1997 priority date.

Obviousness Combination: Sendmail/procmail and Known Administrative Quarantining Principles

A person of ordinary skill in the art in 1997 would have found it obvious to create the system and method described in the '142 patent by combining the known functionalities of the Sendmail MTA with the procmail delivery agent and applying them to solve the known problem of corporate email policy enforcement.

1. Base System: Sendmail and procmail

• What it teaches: By the mid-1990s, Sendmail was the dominant Mail Transfer Agent (MTA) on the internet. In conjunction with procmail, a mail delivery agent (MDA) first developed in 1990, it provided a powerful framework for server-side email processing.
  • Post Office with Rule Engine (Elements a, b, c, d): procmail was explicitly a "mail processing utility" that allowed a system administrator to define rules (so-called "recipes") in a configuration file (.procmailrc) on the server. These rules could filter and sort incoming mail based on sender, subject, keywords in the message body, message size, and other attributes. This directly teaches the concepts of a "post office" storing "business rules" and a "rule engine" that applies them.
  • Applying Actions (Element e): procmail recipes specified actions to be taken on a message if the conditions were met. These actions included delivering the message to a specific mailbox file, piping it to another program, forwarding it, or deleting it (/dev/null). The processing of recipes in a sequence inherently involved a priority system, where the first matching "delivering recipe" would terminate processing. This maps directly to the '142 patent's "distribution engine" applying an action.

2. Secondary Teaching: Known Concepts of Administrative Review and Quarantining

• What it teaches: The concept of isolating or holding messages that violate a policy for administrative review was a known need and practice in system administration, even if the specific term "quarantine" was not uniformly applied in all contexts. The goal was to prevent unwanted or harmful content from reaching end-users while allowing an administrator to review and decide on its final disposition.
  • The "Gating" Action (Element f): A procmail rule could be trivially configured to deliver a message that matched certain criteria (e.g., containing profanity, sent to "All Employees," having a large attachment) to a specific mailbox owned by a system administrator instead of to the intended recipient(s). This is functionally identical to the patent's "gating" action. The administrator would then be the "gatekeeper," who could manually review the message and decide whether to forward it, return it, or delete it. This was not a novel inventive step, but a straightforward application of procmail's existing capabilities.

3. Motivation to Combine

A person of ordinary skill in the art (e.g., a Unix system administrator or email system manager) in the pre-1997 timeframe would have been motivated to implement the claimed invention for several reasons:

• Centralized Corporate Policy Enforcement: As described in the '142 patent's own background section, corporations had policies regarding the distribution of paper documents. As email became a primary communication tool, there was a clear and well-understood need to apply similar policies to electronic messages. A POSITA would naturally look to existing server-side tools to enforce these policies, as relying on individual client applications would be inconsistent and unmanageable.
• Preventing Network Abuse and Inappropriate Content: The need to filter spam and prevent users from sending very large attachments or offensive content was a well-known problem. Using server-side rules to reroute such messages to an administrator for review was a predictable and logical solution.
• Obvious Extension of Existing Functionality: procmail already provided the core mechanisms: rule-based analysis and conditional actions (file, forward, delete). The action of "forwarding to an administrator's mailbox" is not a new type of action but merely a specific application of the existing "forward" or "file to mailbox" action. It would have been an obvious configuration choice for an administrator tasked with enforcing a communication policy.

In summary, the prior art, particularly the widely used combination of Sendmail and procmail, already taught a server-side system with a rule engine that could apply rules to messages and execute actions like filing, forwarding, or deleting. The concept of "gating" a message to a "gatekeeper" is simply a specific, and obvious, implementation of these existing capabilities to solve the known business problem of policy enforcement by having the system forward non-compliant messages to an administrator's mailbox for review. The claims of the '142 patent merely apply new, business-centric labels ("business rules," "gatekeeper") to a well-understood technical framework, which the Federal Circuit correctly identified as an unpatentable abstract idea.

Prosecution and Term Analysis for U.S. Patent 6,073,142

Application and Family Data

• Application Number: 08/881,034
• Filing Date: June 23, 1997
• Issue Date: June 6, 2000
• Continuity: A review of the USPTO's public records, specifically the continuity data for application 08/881,034, shows that this application is a standalone filing. There are no parent applications (such as a provisional or earlier non-provisional) from which it claims priority, nor are there any child continuation or divisional applications that claim priority back to it. This indicates that U.S. Patent 6,073,142 represents the entirety of this specific inventive effort as prosecuted.
• Patent Family: As there are no priority claims to or from other U.S. or foreign applications, U.S. Patent 6,073,142 constitutes its own patent family.

Patent Term Calculation and Expiration

The expiration date of a U.S. patent filed before June 8, 1995, is the later of 17 years from the issue date or 20 years from the filing date. For patents filed on or after June 8, 1995, the term is 20 years from the earliest effective filing date, plus or minus any adjustments.

1. Base Term Calculation:

   • The application for patent 6,073,142 was filed on June 23, 1997.
   • The standard 20-year patent term is calculated from this filing date.
   • Base Expiration Date: June 23, 2017.

2. Patent Term Adjustment (PTA) / Extension (PTE):

   • PTA: The provisions for Patent Term Adjustment (PTA) were established by the American Inventors Protection Act of 1999 and apply to applications filed on or after May 29, 2000. Since the application for the '142 patent was filed in 1997, it was not eligible for PTA. Examination of the patent's file history in the USPTO Patent Center confirms that no PTA was calculated or awarded.
   • PTE: Patent Term Extension (PTE) under 35 U.S.C. § 156, which compensates for regulatory review delays (e.g., by the FDA), is not applicable to this patent as it relates to software methods and not a product requiring such review.

Final Expiration Date

Based on the filing date and the inapplicability of any term adjustments or extensions, the projected and actual expiration date for U.S. Patent 6,073,142 was June 23, 2017. The patent has expired and is no longer in force. All maintenance fees were paid through the end of its term.

Defensive Disclosure and Prior Art Derivations for U.S. Patent 6,073,142

Publication Date: May 11, 2026
Reference: U.S. Patent 6,073,142 ("the '142 patent")

This document discloses novel variations, extensions, and applications of the methods and systems described in the '142 patent. The intent of this disclosure is to place these concepts into the public domain, thereby establishing prior art against future patent applications claiming these or obvious variations thereof.

---

Axis 1: Architectural & Algorithmic Substitution

1.1. Serverless "Post Office" with Atomic Rule Functions

• Enabling Description: The monolithic "post office" architecture is replaced by a set of decoupled, event-driven serverless functions (e.g., AWS Lambda, Google Cloud Functions, Azure Functions) orchestrated via a message queue (e.g., SQS, RabbitMQ). The "receipt engine" is a function triggered by an object's arrival in a storage bucket or message queue. It places a message containing the object's metadata onto a "rules bus." Multiple, independent "rule functions" subscribe to this bus, each embodying a single business rule. Each rule function that is satisfied publishes a proposed "action" object (containing action type, priority, and parameters) to an "actions topic." A final "distribution engine" function is triggered by messages on the actions topic. It collects all actions for a given data object within a defined time window (e.g., 500ms), determines the highest-priority action according to a predefined hierarchy, and executes it. "Gating" involves publishing the original data object's location to a specific "gatekeeper review" queue, which a human-in-the-loop system monitors.

• Mermaid Diagram:

  flowchart TD
      subgraph Serverless Architecture
          A[Data Object Ingest] -->|Object metadata| B(Receipt Engine Function);
          B -->|Publishes to| C{Rules Bus};
          C --> D1[Rule Function 1];
          C --> D2[Rule Function 2];
          C --> Dn[Rule Function N];
          D1 -->|Action Object| E{Actions Topic};
          D2 -->|Action Object| E;
          Dn -->|Action Object| E;
          E --> F(Distribution Engine Function);
          F -->|Executes Highest Priority Action| G{Perform Action};
          G --> G1[Release];
          G --> G2[Delete];
          G --> G3[Gate to Gatekeeper Queue];
      end
  

1.2. Probabilistic Action Selection via Bayesian Inference

• Enabling Description: The deterministic "highest priority" action selection mechanism is replaced with a probabilistic model. The "rule engine" is a Bayesian inference engine. Instead of binary "fired/not fired" rules, each rule contributes evidence that updates a posterior probability distribution over the set of possible actions {release, delete, gate, etc.}. The rule P(Action | Attributes) ∝ P(Attributes | Action) * P(Action) is applied. For example, attributes like "sender is external," "contains financial keywords," and "has attachment > 10MB" increase the probability of the "Gate" action. The distribution engine does not select the highest-priority action but rather the action with the maximum a posteriori (MAP) probability. If the MAP probability is below a certain confidence threshold (e.g., 95%), it defaults to a safe action, such as "Gate." This allows the system to handle uncertainty and combinations of weak signals more gracefully than a rigid priority system.

• Mermaid Diagram:

  flowchart TD
      A[Data Object Received] --> B{Extract Attributes};
      B --> C[Bayesian Inference Engine];
      subgraph Rules as Priors
          R1[P(Gate | Attachment)]
          R2[P(Delete | Keyword)]
          R3[P(Release | Sender)]
      end
      C -- Applies Rules as Evidence --> D{Calculate Posterior Probabilities};
      D --> E[P(Release)=0.1, P(Delete)=0.2, P(Gate)=0.7];
      E --> F{Select Action with Max a Posteriori (MAP)};
      F --> G[Execute: Gate];
  

---

Axis 2: Operational Parameter Expansion

2.1. Gating in High-Latency, Disconnected Tactical Networks

• Enabling Description: This variation applies to edge computing in tactical or intermittently connected environments (e.g., military MANETs, remote industrial sites). The "post office" is a ruggedized edge server with limited connectivity to a central command. Business rules are pre-loaded, but include a "Staleness" attribute. If the connection to central command is lost for a period exceeding a rule's max_staleness parameter, the rule's action is automatically elevated in priority. The "gating" action is localized: the data object is rerouted to the designated local commander's (gatekeeper's) end-user device. A cryptographic hash of the gated object and the gating decision is stored. Upon reconnection, the edge "post office" syncs its log of gated decisions with the central server for audit and potential override. This ensures autonomous local policy enforcement while maintaining central oversight when possible.

• Mermaid Diagram:

  sequenceDiagram
      participant EdgeNode as Edge "Post Office"
      participant Central as Central Command
      participant Operator as Local Gatekeeper
  
      EdgeNode->>EdgeNode: Receive Data Object
      EdgeNode->>Central: Check Connectivity
      alt Connection OK
          EdgeNode->>Central: Sync Rules
          Central-->>EdgeNode: Latest Rules
          EdgeNode->>EdgeNode: Apply Rules normally
      else Connection Lost > max_staleness
          EdgeNode->>EdgeNode: Elevate Priority of Safety Rules
          EdgeNode->>EdgeNode: Trigger Gating Action Locally
          EdgeNode->>Operator: Route object for review
          Operator-->>EdgeNode: Manual Decision (Release/Delete)
      end
      EdgeNode->>Central: (On Reconnect) Sync Decision Log
  

2.2. Nanoscale Gating for On-Chip Data Flows

• Enabling Description: The concept is miniaturized to operate within a System-on-Chip (SoC) or FPGA. The "data objects" are data packets moving across an on-chip bus (e.g., AXI). The "post office" is a dedicated hardware logic block, the "Policy Enforcement Point" (PEP). The "business rules" are stored in on-chip block RAM and define acceptable data flows between IP cores (e.g., "CPU core cannot write directly to RF modulator memory"). The "rule engine" is implemented in HDL as a state machine that inspects packet headers and destinations in real-time. If a rule is violated, the "gating" action stalls the bus transaction and raises an interrupt to a security-supervisor processor core (the "gatekeeper"). This core can then inspect the stalled transaction, kill it, or grant an exception, allowing it to complete. This provides hardware-level security policy enforcement inside a single chip.

• Mermaid Diagram:

  graph TD
      subgraph SoC
          CPU -->|AXI Bus Transaction| PEP(Policy Enforcement Point);
          PEP -- Reads --> BRAM(Rule Store);
          subgraph Rule Example
              R["Rule: Disallow CPU -> RF_MEM Write"]
          end
          BRAM -- Rule --> PEP;
          PEP -->|Transaction Matches Rule| Gate{GATING LOGIC};
          Gate -->|Stall Bus & Interrupt| Supervisor(Security Supervisor Core);
          Supervisor -->|Inspect & Decide| Decision{Kill or Allow};
          Decision -- Allow --> PEP;
          PEP -->|Complete Transaction| RF(RF Modulator Core);
      end
  

---

Axis 3: Cross-Domain Application

3.1. Aerospace: Autonomous Drone Swarm Command Gating

• Enabling Description: In a drone swarm, a ground control station sends a high-level command object (e.g., { "action": "SURVEY", "area": [coords], "altitude": 50 }). The swarm's leader drone acts as the "post office." The "business rules" are the swarm's rules of engagement (ROE), flight safety parameters, and mission constraints (e.g., "Do not descend below 30m in urban zones," "Do not engage targets unless positively identified"). When the leader drone receives a command, its onboard "rule engine" validates it against the ROE. A command that violates a rule (e.g., survey altitude is too low for the zone) is not propagated to the swarm. Instead, it is "gated": the command is rerouted back to the human ground control operator (the "gatekeeper") with a "Request for Confirmation" flag and a description of the rule conflict. The operator must then explicitly override the rule for the command to be executed.

• Mermaid Diagram:

  sequenceDiagram
      participant GCS as Ground Control Station
      participant Leader as Leader Drone (Post Office)
      participant Swarm as Swarm Drones
  
      GCS->>Leader: Send Command Object
      Leader->>Leader: Apply Rules of Engagement (ROE)
      alt Command is ROE-Compliant
          Leader->>Swarm: Propagate Command
          Swarm->>Swarm: Execute Command
      else Command violates ROE
          Leader-->>GCS: Gate Command (Request Confirmation + Reason)
          GCS->>Leader: Send Explicit Override
          Leader->>Swarm: Propagate Overridden Command
      end
  

3.2. AgTech: Smart Irrigation Anomaly Gating

• Enabling Description: A centralized farm management system acts as a "post office" for processing sensor data and generating actuator commands. A "data object" is a scheduled irrigation command, e.g., { "zone": 7, "volume_liters": 5000, "start_time": "02:00" }. The "business rules" database contains crop water requirements, weather forecast data, soil moisture thresholds, and electricity pricing tiers. The "rule engine" processes the command before sending it to the irrigation controller. A rule might be: "IF weather_forecast.rain_chance > 80% THEN Action=DELETE" or "IF command.volume_liters > (2 * historical_avg) THEN Action=GATE". If the "GATE" action is triggered, the command is not sent to the pump controller. Instead, it is placed in a "review queue" on the farm manager's dashboard (the "gatekeeper"), who must manually approve the unusually high water usage before it is executed.

• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Scheduled
      Scheduled: Command Created {zone:7, vol:5000}
      Scheduled --> Rule_Engine: Process Command
  
      state Rule_Engine {
        [*] --> Check_Weather
        Check_Weather --> Check_Anomaly : [Rain <= 80%]
        Check_Weather --> Deleted : [Rain > 80%]
        Check_Anomaly --> Approved : [Volume < 2x Avg]
        Check_Anomaly --> Gated : [Volume >= 2x Avg]
      }
  
      Approved --> Executed: Command sent to pump
      Gated --> Awaiting_Review: On Manager Dashboard
      Awaiting_Review --> Executed: Manager Approves
      Awaiting_Review --> Deleted: Manager Rejects
      Executed --> [*]
      Deleted --> [*]
  

3.3. Consumer Electronics: Smart Home Command Arbitration

• Enabling Description: A smart home hub (e.g., Home Assistant, Amazon Echo) acts as the "post office" for commands from various sources (voice, mobile app, automations). A command to lock_front_door is a data object. The "business rules" represent household policies: "Never lock the front door if presence_sensor.people_inside == 0," or "If time > 23:00 and command is unlock_front_door, action is GATE." The "gatekeeper" is the primary homeowner's smartphone. If a late-night unlock command is issued by a guest's voice, the hub "gates" it by sending a high-priority push notification to the homeowner's phone: "Guest is attempting to unlock the front door. [Allow] [Deny]". The door remains locked until the gatekeeper manually allows the action.

• Mermaid Diagram:

  classDiagram
  class SmartHomeHub {
      +receiveCommand(Command)
      -applyRules(Command)
      -executeAction(Action)
  }
  class RuleEngine {
      +evaluate(Command, HouseState) ActionList
  }
  class HouseState {
      +people_inside: int
      +time_of_day: Time
  }
  class Command {
      +source: string
      +action: string
      +target: string
  }
  class GatekeeperDevice {
      +receiveGatedRequest(Command)
      +sendApproval()
      +sendDenial()
  }
  SmartHomeHub o-- RuleEngine
  SmartHomeHub o-- HouseState
  SmartHomeHub "1" -- "n" GatekeeperDevice : Notifies
  RuleEngine ..> Command
  

---

Axis 4: Integration with Emerging Tech

4.1. AI-Driven Predictive Gating with RLHF

• Enabling Description: The static, human-written "database of business rules" is replaced with a machine learning classification model (e.g., a gradient-boosted tree or a neural network). The model is trained on a massive corpus of historical data objects and the actions that were taken on them. The model ingests a new data object and outputs a risk score (0.0 to 1.0) and a recommended action. If the risk score exceeds a dynamic threshold, the system's action is to "gate" the object to a human gatekeeper. The key innovation is the feedback loop: the gatekeeper's final decision (e.g., releasing a message the AI flagged, or deleting one it missed) is used as a new labeled data point to continuously retrain and fine-tune the model, a process known as Reinforcement Learning from Human Feedback (RLHF). This allows the system to adapt to new threats and policies without manual rule rewriting.

• Mermaid Diagram:

  flowchart LR
      subgraph Inference
          A[Data Object] --> B(Feature Extraction);
          B --> C[ML Model];
          C --> D{Risk Score > Threshold?};
      end
      subgraph Gatekeeper Review
          E[Gatekeeper UI] -->|Approve/Deny| F{Final Action};
      end
      subgraph Training Loop (RLHF)
          G[Action Log] --> H(Model Retraining);
      end
      D -- Yes --> E;
      D -- No --> F;
      F --> G;
  

4.2. Blockchain-Based Immutable Gating with Smart Contracts

• Enabling Description: The system is implemented on a permissioned blockchain (e.g., Hyperledger Fabric). The "business rules" are encoded as functions within a smart contract. The "post office" is a network node that receives an off-chain data object. The node initiates a transaction on the blockchain by calling the smart contract's evaluate() function, passing in a hash of the data object and its metadata. The smart contract logic (the "rule engine") executes on all peer nodes. If the logic determines a "gate" action is required, the contract enters a PendingApproval state and emits an event. This state requires a multi-signature transaction to proceed, with the required signatures belonging to the cryptographic wallets of the designated "gatekeepers." A gatekeeper approves by signing a release() transaction call. The entire sequence—initial evaluation, gating, and final resolution—is recorded as an immutable, cryptographically verifiable series of transactions in the blockchain ledger, providing unparalleled auditability.

• Mermaid Diagram:

  sequenceDiagram
      participant User
      participant AppNode as Application Node
      participant Blockchain
      participant Gatekeeper
  
      User->>AppNode: Submit Data Object
      AppNode->>Blockchain: Invoke evaluate(dataHash) on Smart Contract
      Blockchain->>Blockchain: Contract logic executes (Rule Engine)
      alt Gate Condition Met
          Blockchain->>Blockchain: Set state to PendingApproval
          Blockchain-->>Gatekeeper: Emit ApprovalRequest Event
          Gatekeeper->>Blockchain: Invoke release(dataHash) with signature
          Blockchain->>Blockchain: Validate signature; execute release logic
      else Gate Condition Not Met
          Blockchain->>Blockchain: Execute default logic (e.g., release)
      end
  

---

Axis 5: The "Inverse" or Failure Mode

5.1. Fail-Secure Gating Default

• Enabling Description: The system is designed with a "fail-secure" or "fail-closed" posture. The "distribution engine" is wrapped in a monitoring process or circuit breaker. If the rule engine service fails to return a decision within a specified timeout (e.g., 1 second), if it crashes, or if its connection to the rule database is lost, the monitoring process intercepts the data object. Instead of allowing it to pass or failing entirely, it enforces a default "gate-all" policy. The object is immediately shunted to a high-priority "quarantine" or "dead-letter" queue designated for system failure review. An alert is automatically sent to system administrators (the default gatekeepers for this scenario), notifying them of the failure and the location of the quarantined objects. This prevents data leakage or policy bypass during system outages.

• Mermaid Diagram:

  stateDiagram-v2
      state "Processing" as P
      [*] --> P
      P --> Released: Rule Engine -> Release
      P --> Deleted: Rule Engine -> Delete
      P --> Gated: Rule Engine -> Gate
      P --> Quarantined: Rule Engine -> Timeout/Error
  
      Quarantined: Object gated due to system failure
      Quarantined --> Manual_Review
      Manual_Review --> Released
      Manual_Review --> Deleted
  

5.2. Tiered Gating with Graceful Degradation

• Enabling Description: The system operates in multiple modes to gracefully handle resource constraints (e.g., high load, low power). In "Full Mode," the complete, computationally expensive rule set is applied. If system load exceeds a threshold (e.g., CPU > 90%), it enters "Degraded Mode." In this mode, only a pre-defined subset of high-priority, low-cost rules (e.g., simple keyword matching) is executed. All other data objects are "soft-gated"—they are released to their destination but are tagged with a review_required flag, and their metadata is logged to a queue for asynchronous, delayed review once system load returns to normal. This ensures critical policies are still enforced in real-time while preventing system collapse and creating a backlog for eventual consistency.

• Mermaid Diagram:

  flowchart TD
      A[Data Object] --> B{Check System Load};
      B -- Load < 90% --> C[Full Rule Set Engine];
      C --> D{Apply Actions};
      B -- Load >= 90% --> E[Degraded Mode Engine];
      subgraph Degraded Mode Engine
          E1[Apply Critical Rules Only] --> E2{Triggered?};
      end
      E2 -- Yes --> D;
      E2 -- No --> F[Release with 'Review Required' Tag];
      F --> G[Log for Async Review];
  

---

Combination Prior Art with Open-Source Standards

Scenario 1: Gating SMTP Messages based on DMARC & SPF

• Enabling Description: A mail transfer agent (MTA) acting as a "post office" (e.g., Postfix, Exim) integrates a policy daemon that functions as the "rule engine." When an email is received, the MTA first performs standard DMARC, SPF, and DKIM validation. The results of these checks (pass, fail, softfail, none) are passed to the policy daemon as attributes of the message. A business rule can now be defined as: "IF (dmarc.result == 'fail' OR spf.result == 'fail') AND header.from matches domain-list:financial_partners THEN Action=GATE, Gatekeeper=soc-team@example.com." This combines standard internet email authentication protocols with the '142 patent's gating logic to create a sophisticated anti-phishing and anti-spoofing system where marginal authentication failures from critical partners are routed for human analysis rather than being automatically rejected or delivered.

Scenario 2: Gating HTTP API Calls based on JWT Claims

• Enabling Description: A cloud-native API Gateway (e.g., Kong, Tyk) serves as the "post office" for all incoming microservice requests. Every request must include a JSON Web Token (JWT) in its Authorization header. The gateway acts as the "rule engine," validating the JWT's signature and then inspecting its payload (claims). Business rules are defined based on these claims: "IF request.path matches /admin/* AND jwt.claims.role != 'admin' THEN Action=GATE." The "gating" action is implemented by forwarding the original request object to a separate "security approval" service and returning an HTTP 202 Accepted status to the original client with a location header pointing to a status-check endpoint. A security officer (gatekeeper) reviews the request in a dashboard and, upon approval, the security service re-plays the original request with an elevated-privilege token.

Scenario 3: Gating MQTT Messages in an IoT Network based on OPC UA Models

• Enabling Description: An MQTT broker (e.g., Mosquitto, EMQ X) is configured with a rule engine plugin. The broker is the "post office" for messages from industrial sensors and actuators. The "business rules" are defined using the standardized information models from OPC UA, which describe the valid states and operating parameters of industrial equipment. A sensor publishes a JSON payload to an MQTT topic: topic: 'factory/press-1/pressure', payload: { 'value': 950, 'units': 'kPa' }. The rule engine loads the OPC UA model for press-1 and knows the max_pressure is 900 kPa. A rule states: "IF payload.value > opcua.model.max_pressure THEN Action=GATE, Gatekeeper=topic:factory/press-1/alerts." The "gating" action simultaneously publishes the anomalous message to an alert topic for human review and sends a command via MQTT to a safety PLC to halt the machine, preventing damage.