US 6460050

Patent Analysis: US 6460050 B1

Date of Analysis: May 11, 2026

Summary

Title: Distributed content identification system

Assignee: As of the latest assignment records, the patent is assigned to Intellectual Ventures I LLC. The original assignee was listed as "Individual".

Inventors: Mark Raymond Pace, Brooks Cash Talley

Filing Date: December 22, 1999

Issue Date: October 1, 2002

Abstract:
A file content classification system includes a digital ID generator and an ID appearance database coupled to receive IDs from the ID generator. The system further includes a characteristic comparison routine identifying the file as having a characteristic based on ID appearance in the appearance database. In a further aspect, a method for identifying a characteristic of a data file comprises the steps of: generating a digital identifier for the data file and forwarding the identifier to a processing system; determining whether the forwarded identifier matches a characteristic of other identifiers; and processing the data file based on said step of determination.

---

Plain-Language Overview of Independent Claims

US Patent 6460050 has five independent claims (1, 9, 16, 21, and 22). Below is a simplified explanation of each.

Claim 1: Describes a system for classifying files. This system is made up of multiple "agents" (software components) installed on different client computers. Each agent can create a unique digital ID for a file's content using a mathematical formula. These IDs are sent to a central server that has a database for storing them. The server then analyzes how often it sees a particular ID to determine a characteristic of the file (e.g., if it's spam) and sends this classification back to the client agents.

Claim 9: Outlines a method for identifying file characteristics. A central processing system receives unique file content IDs from multiple software agents running on different source computers. The processing system then checks if a received ID matches a known characteristic based on other IDs it has seen. Finally, it sends a notification of this characteristic back to at least one of the source computers that requested the analysis.

Claim 16: Details a method specifically for filtering email. A central computer receives a unique digital ID for an email's content from at least two different user computers. This central computer compares the ID against its database of other IDs to see if the email has a certain characteristic (like being spam). It then responds to a query from a user's computer, informing it whether that characteristic is present or not.

Claim 21: Focuses on a file classification system that operates between two computers over a network. The first computer (the client) has an agent that generates a file ID by calculating a value from at least two separate, non-adjacent parts of the file's data. The second computer (the server) has an agent and a database that receives these IDs and sends replies back. The client agent then takes action on the file based on the server's reply.

Claim 22: Describes a method for providing a service over the Internet. A central server collects data, specifically unique digital content IDs for various files, from multiple systems that have a client agent installed. The server then characterizes these files by comparing their IDs to the collection of other IDs in its database. Finally, the server sends a "substance identifier" back to the client agent, indicating whether a specific characteristic was found in the file.

Litigation Status

It is important to note that claims of US Patent 6460050 have been subject to significant legal scrutiny. In the case of Intellectual Ventures I LLC v. Symantec Corp., the U.S. Court of Appeals for the Federal Circuit (CAFC) affirmed a district court's decision that the asserted claims of this patent are invalid because they are directed to an abstract idea and lack an inventive concept, rendering them ineligible for patent protection under 35 U.S.C. § 101. This legal precedent significantly impacts the enforceability of this patent.

Known Litigation

Building on the summary previously provided, U.S. Patent No. 6,460,050 has been the subject of extensive and significant litigation. The patent was asserted by Intellectual Ventures I LLC against several major players in the cybersecurity industry. The primary legal battle unfolded in the U.S. District Court for the District of Delaware and was subsequently appealed to the U.S. Court of Appeals for the Federal Circuit (CAFC).

Below is a detailed list of the known legal cases involving this patent.

District Court Litigation

• Case Name: Intellectual Ventures I LLC v. Symantec Corp., et al.
• Plaintiff: Intellectual Ventures I LLC
• Defendants: Symantec Corp., Trend Micro Inc., and McAfee, Inc.
• Jurisdiction: U.S. District Court for the District of Delaware
• Case Numbers:
  • 1:10-cv-01067-LPS (Original action against Symantec)
  • 1:12-cv-01580-LPS (Action against McAfee)
  • 1:12-cv-01581-LPS (Action against Trend Micro and the lead number for the consolidated cases)
• Filing Dates: The initial case against Symantec was filed on December 6, 2010. The cases against McAfee and Trend Micro were filed on November 30, 2012, and were subsequently consolidated with the Symantec case.
• Outcome/Status: After a jury trial against Symantec where the jury did not find the patent invalid under §§ 102 or 103, the defendants filed motions for judgment on patent ineligibility under 35 U.S.C. § 101. On May 1, 2015, the district court granted summary judgment to the defendants, ruling that the asserted claims of U.S. Patent No. 6,460,050 were invalid because they were directed to the abstract idea of filtering content without an inventive concept.

Appellate Litigation

The district court's decisions were appealed to the U.S. Court of Appeals for the Federal Circuit (CAFC) in a series of related cases.

• Case Name: Intellectual Ventures I LLC v. Symantec Corp.

• Plaintiff-Appellant: Intellectual Ventures I LLC

• Defendants-Appellees: Symantec Corp., Trend Micro Inc.

• Jurisdiction: U.S. Court of Appeals for the Federal Circuit

• Case Numbers: 15-1770, 15-1769, 15-1771 (consolidated)

• Outcome/Status: On September 30, 2016, the CAFC affirmed the district court's ruling of invalidity. The court concluded that the patent claims were directed to the abstract idea of "receiving, screening, and distributing email," a long-prevalent real-world practice, and that implementing this idea on generic computers was not a sufficient inventive concept to warrant patent protection under 35 U.S.C. § 101. This decision is frequently cited in subsequent cases concerning software patent eligibility.

• Case Name: Intellectual Ventures I LLC v. Trend Micro Inc.

• Plaintiff-Appellant: Intellectual Ventures I LLC

• Defendants-Appellees: Trend Micro Inc., Trend Micro, Inc. (USA)

• Jurisdiction: U.S. Court of Appeals for the Federal Circuit

• Case Number: 19-1122

• Outcome/Status: This appeal related to the district court's award of attorneys' fees to Trend Micro after finding the case exceptional due to inconsistent testimony from the plaintiff's expert. In a decision on December 19, 2019, the CAFC vacated the fee award and remanded the case, instructing the district court to reconsider the award under the "totality of the circumstances."

These cases collectively represent a significant legal challenge to the validity and enforceability of U.S. Patent No. 6,460,050, culminating in a definitive appellate ruling that its key claims are invalid as a matter of law.

Proceedings overview

One Covered Business Method (CBM) review was filed against US patent 6460050, resulting in the invalidation of all challenged claims that were instituted for trial, including all independent claims except claim 21. This outcome, which was affirmed on appeal, provides a defendant with an extremely strong defensive posture, as any infringement assertion based on the invalidated claims is baseless.

CBM2014-00114 — Symantec Corporation v. Intellectual Ventures I LLC

• Type: Covered Business Method (CBM) Review
• Filed: 2014-04-07
• Status: Terminated - Final Written Decision. The PTAB found the challenged, instituted claims unpatentable. This decision was affirmed by the U.S. Court of Appeals for the Federal Circuit.
• Judge panel: Administrative Patent Judges Michael P. Tierney, Jameson Lee, and Thomas L. Giannetti.
• Petition grounds: Symantec Corporation petitioned for review of claims 1–25, asserting they were unpatentable as being directed to an abstract idea under 35 U.S.C. § 101 and as obvious under 35 U.S.C. § 103 over various prior art references.
• Institution decision: On 2014-10-09, the PTAB instituted trial on claims 1, 4, 8, 9, 13–16, 20, and 22–25 on § 101 grounds only. The panel determined the patent was eligible for CBM review as its claims were directed to "a method or corresponding apparatus for performing data processing or other operations used in the practice, administration, or management of a financial product or service." The Board agreed at the institution stage that the claims were likely directed to the abstract idea of "receiving, processing, and replying to data."
• Final Written Decision: Issued on 2015-10-06. The PTAB determined that claims 1, 4, 8, 9, 13–16, 20, and 22–25 are unpatentable under 35 U.S.C. § 101. The panel found the claims were directed to the abstract idea of "content-based filtering of data." It concluded that the claim elements, viewed individually and as an ordered combination, did not supply an "inventive concept" sufficient to transform the abstract idea into a patent-eligible application. The claims were seen as merely requiring generic computer components to perform their conventional functions.
• Settlement / termination: The proceeding was not terminated due to settlement; it concluded with a Final Written Decision on the merits.
• Appeal: Intellectual Ventures I LLC appealed the PTAB's decision to the Federal Circuit. On 2017-09-13, in case no. 2016-1188, the Federal Circuit issued a summary affirmance under Rule 36, upholding the PTAB's invalidation of the claims. This was part of the same oral argument session that addressed the appeal from the district court litigation, which had reached the same conclusion on patent ineligibility.
• Defensive value: Extremely high. This proceeding invalidates independent claims 1, 9, 16, and 22, along with several dependent claims. Any infringement theory built on these specific claims is untenable, as they have been found unpatentable by the USPTO and that finding was affirmed by the Federal Circuit.

Strategic summary

The PTAB's review has significantly impacted the enforceability of US patent 6460050. All independent claims (1, 9, 16, 22) and their dependent claims that were reviewed in CBM2014-00114 have been canceled. The only independent claim not invalidated in this proceeding is claim 21, as trial was not instituted on it.

• CANCELED: Claims 1, 4, 8, 9, 13, 14, 15, 16, 20, 22, 23, 24, and 25.
• SUSTAINED: None.
• UNTESTED in FWD: Claims 2, 3, 5–7, 10–12, 17–19, and 21. While the petition originally challenged these claims, the PTAB did not institute trial on them, so no final decision was rendered on their patentability in this proceeding. However, it is critical to note that the parallel district court litigation (Intellectual Ventures I LLC v. Symantec Corp.) resulted in a Federal Circuit opinion finding the claims ineligible under § 101, which casts serious doubt on the validity of any remaining claims that are substantially similar.

For a defendant facing an assertion today, the estoppel landscape is favorable. While the petitioner (Symantec) is barred under 35 U.S.C. § 315(e)(2) from re-litigating grounds that it raised or reasonably could have raised, a new defendant is not. More importantly, the § 101 invalidity holding from the CBM review and its affirmance provide a powerful, publicly-available defense that does not depend on prior art. The patent owner, Intellectual Ventures, has demonstrated a willingness to appeal adverse decisions, but in this instance, both the PTAB and district court invalidity rulings were upheld.

Recommended next steps

If you are a defendant and have received a demand letter citing US patent 6460050, your response should be direct and firm, especially if the letter cites any of the invalidated claims.

1. Reference the CBM Proceeding: Explicitly cite the Final Written Decision in CBM2014-00114 and the subsequent Federal Circuit affirmance (Appeal No. 2016-1188). You should state that the asserted claims have been found unpatentable by the USPTO.

   "The Final Written Decision for CBM2014-00114, issued October 6, 2015, and available from the USPTO Patent Trial and Appeal Board, states: 'we determine that petitioner has shown by a preponderance of the evidence that claims 1, 4, 8, 9, 13–16, 20, and 22–25 of the ’050 patent are unpatentable under 35 U.S.C. § 101.' This decision was summarily affirmed by the Court of Appeals for the Federal Circuit."

2. Reference the Parallel Federal Court Litigation: In addition to the PTAB proceeding, cite the Federal Circuit’s decision in Intellectual Ventures I LLC v. Symantec Corp., 838 F.3d 1307 (Fed. Cir. 2016), which also held the patent invalid under 35 U.S.C. § 101. This separate court ruling provides an independent and powerful basis for invalidity, likely covering any remaining untested claims of a similar nature.

3. Assess Untested Claims: If the assertion is based on the small subset of claims not invalidated in the CBM (e.g., claim 21), a thorough analysis should be conducted to determine if the reasoning from the CBM and Federal Circuit court decisions applies equally to them. Given the breadth of the court's reasoning on the abstract idea of "content-based filtering," it is highly probable that any remaining claims are also invalid.

Inventors

• Mark Raymond Pace
• Brooks Cash Talley

The patent was filed by the inventors as individuals, and no corporate assignee was named on the issued patent. There is no information in the record to suggest they were employed by a single entity at the time of filing or that they departed an employer around the filing date.

Original assignee

The patent was originally assigned to the inventors themselves, Mark Raymond Pace and Brooks Cash Talley. There is no evidence that the inventors or a company they formed ever commercialized a product embodying the claims of the patent.

Assignment timeline

• 2006-08-23 (executed) / recorded 2006-09-18 — Reel 017997/0118

  • Conveyance: Assignment
  • Assignor: Mark Raymond Pace and Brooks Cash Talley
  • Assignee: Terranco, Limited Liability Company
  • Correspondent: James J. Korty, Heim, Payne & Chastain, L.L.P., 600 Travis, Suite 6710, Houston, TX 77002
  • Context: The inventors transferred the patent to a holding company, a common first step before licensing or sale.

• 2010-12-07 (recorded) — Reel 025539/0789

  • Conveyance: Merger
  • Assignor: Terranco, Limited Liability Company
  • Assignee: Intellectual Ventures I LLC
  • Correspondent: Intellectual Ventures, Attn: IP Docketing, 717 Bellevue Ave NE, Bellevue, WA 98004
  • Context: The patent was acquired by a major patent assertion entity as part of a merger involving the prior holding company.

Timeline diagram

timeline
    title Ownership of US 6460050
    1999 : Filed by inventors Pace and Talley
    2002 : Issued
    2006 : Assigned to Terranco LLC
    2010 : Acquired by Intellectual Ventures I LLC
         : First infringement suit filed vs Symantec

NPE / troll-pattern signals

1. Shell-entity transfer — Present. The inventors first transferred the patent to Terranco, Limited Liability Company (Reel 017997/0118), a holding entity, which then transferred it to Intellectual Ventures I LLC (Reel 025539/0789).

2. Known asserter in the chain — Present. The current assignee of record is Intellectual Ventures I LLC (Reel 025539/0789), one of the most widely recognized patent assertion entities (NPEs).

3. Repeat correspondent across the chain — Not present. The two recorded assignments list different correspondents.

4. Cascading transfers — Not present. The transfers occurred approximately four years apart.

5. Pre-litigation transfer — Present. The assignment to Intellectual Ventures I LLC was recorded on 2010-12-07 (Reel 025539/0789). The first infringement lawsuit on this patent, Intellectual Ventures I LLC v. Symantec Corp., was filed the very next day on 2010-12-08 in the District of Delaware (Case 1:10-cv-01067). This timing indicates the transfer was recorded to perfect legal standing immediately before litigation commenced.

6. Bankruptcy fire-sale — Not present. There is no evidence of a bankruptcy proceeding in the assignment chain.

7. Privateering — Not present. The original assignors were the inventors, not an operating company offloading patents for assertion against its competitors.

8. Defensive aggregator (anti-NPE) — Not present. The chain terminates with a known patent assertion entity.

Verdict

NPE — high confidence

The assignment chain shows a clear and deliberate path to monetization through assertion, not commercialization. The patent was moved from the inventors to a holding company (Terranco, LLC) and then acquired by Intellectual Ventures, a well-known NPE (Reel 025539/0789). The final assignment was recorded just one day before the first lawsuit was filed, demonstrating a clear intent to litigate.

Verification link: USPTO Assignment Search for US 6460050

Prior Art Analysis for US Patent 6460050

The following analysis details prior art references cited during the examination of US Patent 6460050. These references were considered by the USPTO examiner and are relevant to understanding the patent's claims and novelty. The critical date for prior art is the patent's filing date of December 22, 1999.

U.S. Patent Documents Cited

1. US Patent 5,619,648 - "Method for screening electronic messages for a computer user" (Canale et al.)

• Full Citation: US Patent 5,619,648, Canale, et al., issued April 8, 1997.
• Filing Date: June 7, 1995.
• Brief Description: This patent describes a system for filtering electronic mail (e-mail) based on user-defined criteria. A user can create "screening criteria" which are applied to incoming e-mails. If a message matches the criteria, a user-specified action is performed, such as deleting the message, moving it to a specific folder, or forwarding it. This system acts as an agent for the user to manage unwanted messages automatically.
• Potential Anticipation: This reference is highly relevant to the general concept of e-mail filtering. It teaches receiving a message, applying a rule or filter to it, and then taking an action. However, it appears to focus on user-defined rules (like filtering based on sender or subject keywords) implemented on the user's system or a local server, rather than the distributed, collaborative model of US 6460050. It does not explicitly teach the generation of a content-based digital ID (like a hash) and sending it to a remote server that aggregates data from multiple, separate clients to determine the characteristic of the message (e.g., as spam). Therefore, while it describes a form of filtering, it likely does not anticipate the specific distributed and collaborative architecture claimed in independent claims 1, 9, 16, and 22 of US 6460050.

2. US Patent 5,999,932 - "System and method for filtering unwanted electronic mail" (Pauloski)

• Full Citation: US Patent 5,999,932, Pauloski, issued December 7, 1999.
• Filing Date: August 11, 1997.
• Brief Description: This patent discloses a collaborative e-mail filtering system where users can vote on whether a message is unwanted "junk" e-mail. A server maintains a database of messages and their associated "junk" votes. When a new message arrives, its content (or a representation of its content) is compared to the database. If the message has been widely identified as junk by other users, it is blocked or filtered.
• Potential Anticipation: This reference is very strong prior art. It teaches a client-server model where multiple users (clients) contribute to a central database to identify unwanted content. This directly relates to the core concept of leveraging data from a plurality of systems, as recited in claims 1, 9, 16, and 22. The system compares an incoming message to this collective database to characterize it. While it may not explicitly use the term "hash" or "digital ID," it describes comparing message content, which is the functional equivalent. This patent could be argued to anticipate the core ideas of claim 1 (plurality of agents, server database, characteristic comparison), claim 9 (receiving identifiers from multiple agents), claim 16 (comparing an identifier to a database of identifiers from multiple computers), and claim 22 (collecting data from a plurality of systems to characterize files).

3. US Patent 6,023,723 - "Snooping TCP" (McCormick et al.)

• Full Citation: US Patent 6,023,723, McCormick, et al., issued February 8, 2000.
• Filing Date: October 29, 1997.
• Brief Description: This patent describes a system for monitoring (snooping) network traffic, specifically TCP/IP packets, to filter content. It discloses an apparatus that sits between a local network and an external network (like the Internet) and inspects packets for certain content, such as viruses or specific keywords. This can be used to block unwanted data from entering the local network.
• Potential Anticipation: This reference teaches content inspection and filtering at a network level. It supports the general environment in which the '050 patent operates. However, its focus is on packet-level inspection based on predefined rules for a single network, not the collaborative, hash-based system described in the '050 patent. It does not appear to teach creating a content ID and sending it to a remote, multi-user database for characterization based on frequency or appearance across different networks. It therefore seems less relevant for anticipating the core distributed and collaborative claims (1, 9, 16, 22).

4. US Patent 6,161,130 - "System and method for reducing transmission of unsolicited bulk electronic mail" (Horvitz et al.)

• Full Citation: US Patent 6,161,130, Horvitz, et al., issued December 12, 2000.
• Filing Date: September 18, 1998.
• Brief Description: This patent discloses a method for identifying and filtering unsolicited bulk e-mail (UBE) by analyzing message attributes. The system can create a "fingerprint" or "signature" of a message and store it. When new messages arrive, their fingerprints are compared against the database of known UBE fingerprints. A key aspect is the ability to identify messages that are substantially similar, even if not identical, which is common in spam campaigns.
• Potential Anticipation: This is another very strong prior art reference. The concept of creating a message "fingerprint" or "signature" is functionally identical to the "digital content identifier" or "file content ID" in US 6460050. The system compares these fingerprints against a database to classify new messages. The reference contemplates a centralized analysis of message attributes to identify spam campaigns. This strongly relates to claims 1, 9, 16, and 22. If the reference also suggests that this fingerprint database is built from inputs from multiple distributed users or systems, it would be a very direct anticipation of the core invention claimed in US 6460050.

Non-Patent Literature Cited

The file wrapper also lists several non-patent references, including two that are particularly relevant:

• "Distributed Checksum Clearinghouse" (www.rhyolite.com/anti-spam/dcc): The DCC is a known anti-spam system that collects checksums (a type of hash or digital ID) of mail messages from various client sites. A central server counts how many times it sees each checksum. If a message is reported by many different clients, it is classified as bulk mail. This system, which existed before the 1999 filing date of the '050 patent, appears to be a direct implementation of the core inventive concept.
• "Vipul's Razor" (razor.sourceforge.net): Similar to the DCC, Razor was a collaborative, distributed spam filtering network. Users would generate signatures of spam messages and submit them to a central catalog. Other users' mail servers could then check incoming mail against this catalog to identify and filter known spam.

Potential Anticipation by Non-Patent Literature: Both the DCC and Razor systems appear to disclose all the key elements of the independent claims of US 6460050. They both describe:

• Client agents on multiple computers (Claims 1, 9, 22).
• Generating a digital identifier (checksum/signature) of an e-mail's content (Claims 1, 9, 16, 22).
• Sending this identifier to a central server with a database (Claims 1, 21, 22).
• The server determining a characteristic (spam) based on the collection of identifiers from multiple clients (Claims 1, 9, 16, 22).
• Returning a reply to the client to enable filtering (Claims 1, 9, 16, 21, 22).

These systems represent a significant challenge to the validity of the patent's claims under 35 U.S.C. § 102 (anticipation) and § 103 (obviousness). The existence of these real-world, publicly documented systems before the patent's filing date corroborates the findings of invalidity in the later court and PTAB proceedings.

Obviousness Analysis under 35 U.S.C. § 103

This analysis evaluates the obviousness of the claims of US patent 6460050 in light of prior art existing before the priority date of December 22, 1999. The core concept of the patent—using a digital identifier (hash) generated on a client machine, sending it to a central server, and using a collective database of these identifiers to classify content like spam or viruses—can be rendered obvious by combining existing technologies and known techniques from that era.

A person having ordinary skill in the art (PHOSITA) at the time would have been a computer scientist or software engineer with experience in network protocols, email systems, and cybersecurity, including antivirus and anti-spam techniques.

Primary Obviousness Combination

A strong argument for obviousness can be constructed by combining the teachings of distributed antivirus signature systems with known hashing algorithms for file identification.

1. Distributed Antivirus Technology (The "How"): By the late 1990s, antivirus software was a mature industry. Companies like Symantec and McAfee employed a client-server model where individual computers (clients) would run software that scanned files. These clients would periodically connect to a central server to download updated "signature" files. These signatures were essentially unique identifiers for known viruses. This established the model of a distributed network of agents all reporting to, and receiving updates from, a central authority to identify unwanted content. The fundamental architecture of a "plurality of agents" (the antivirus software on user machines) communicating with a central "server" having a "database" (the virus signature database) was well-established and ubiquitous.

2. Content Hashing for Identification (The "What"): Hashing algorithms like MD5 and SHA-1 were well-known and standardized before 1999. They were widely used for verifying file integrity and creating unique, compact "digital fingerprints" or "identifiers" for any piece of digital data. A PHOSITA would have been well aware that hashing was the standard method for creating a unique, fixed-size identifier from a variable-sized piece of content (like an email body or a file). The use of a hash as a "digital ID" was a common and fundamental computer science technique.

Motivation to Combine

The motivation to combine these two established concepts would have been driven by the clear and pressing need for a more efficient and scalable solution to the burgeoning problem of email spam.

By 1999, spam was a significant issue. Simple client-side keyword filtering was becoming ineffective as spammers adapted their methods. Sending entire emails to a third-party service for analysis was recognized as being slow, costly in terms of bandwidth, and raising privacy concerns—problems explicitly mentioned in the background of the '050 patent itself.

A PHOSITA, tasked with creating a better spam filter, would have naturally looked at the successful model used for combating viruses. The analogy is direct:

• Viruses are unwanted files. Spam is an unwanted email.
• The antivirus model uses a compact signature to identify a virus without needing to see the whole file every time.
• Spam emails, particularly from a single campaign, are often identical or nearly identical.

The logical and obvious step would be to apply the proven, efficient client-server signature model from the antivirus world to the spam problem. Instead of a virus signature, the PHOSITA would use a hash of the email's content as the signature. This approach would be highly efficient, as only a small hash value would need to be transmitted over the network, solving the bandwidth and privacy issues of sending the entire email. The central server could then identify spam by observing that many different clients were submitting the exact same hash in a short period—a clear indicator of a mass-mailing campaign.

Analysis of Independent Claims

Claim 1: A file content classification system...

• "a plurality of agents, each agent including a file content ID generator creating file content IDs using a mathematical algorithm": This is disclosed by the combination. The "agents" are analogous to the distributed antivirus clients. The "file content ID generator" is the known hashing algorithm (e.g., MD5) that the PHOSITA would obviously select to create a unique signature for an email.
• "an ID appearance database, provided on a server, coupled to receive file content IDs from the agents": This describes the central antivirus signature server and its database, adapted to store hashes instead of virus signatures. The network connectivity is inherent to the client-server model.
• "a characteristic comparison routine on the server, identifying a characteristic of the file content based on the appearance of the file content ID": This is the core logic of the central server. In the antivirus world, the "characteristic" is "is a virus," determined by checking if the file's signature is in the database. For spam, the obvious "characteristic" would be "is spam," and the "comparison routine" would be a simple algorithm to check if a hash appears with a high frequency from multiple agents, as motivated above.
• "transmitting the characteristic to the client agents": This is the standard final step in the client-server model. The server informs the client of the result so the client can take action (e.g., quarantine a virus, or in this case, delete or flag spam).

Claim 9 & 16: A method for identifying characteristics... / A method of filtering an email message...

These method claims mirror the system of claim 1 and are rendered obvious by the same combination of prior art. The steps of "receiving... file content identifiers... from a plurality of... agents," "determining... whether each received content identifier matches a characteristic," and "outputting... an indication of the characteristic" are the direct and obvious implementation of the combined antivirus/hashing model applied to spam filtering.

Claim 21: A file content classification system... a computed value of at least two non-contiguous sections of data in a file...

This claim adds the limitation that the identifier is computed from "at least two non-contiguous sections of data." This was a known technique for making identifiers more robust against minor changes. Spammers in the late 1990s had already begun to add random text or extra whitespace to the end of messages to try and defeat simple hashing of the entire file. A PHOSITA would have considered it an obvious and routine design choice to create a more resilient hash by selecting stable parts of the message (e.g., the first 500 bytes and the last 500 bytes of the body, or the subject line and part of the body) and concatenating them before hashing. This would be a predictable adaptation to circumvent known evasion techniques and does not constitute an inventive step.

Claim 22: A method for providing a service on the Internet...

This claim describes the invention as an internet "service." The combination of distributed clients (antivirus software) communicating over the internet with a central server (the update server) to provide a service (virus protection) was the standard business and technical model for this type of software in 1999. Applying this same service model to spam filtering by substituting hashes for virus signatures would have been an obvious commercial and technical implementation. The steps of "collecting data," "characterizing the files... based on said digital content identifiers," and "transmitting a substance identifier" are all present in the proposed obvious combination.

Term, Continuity, and Family Data

Patent Term and Expiration

• Application Filing Date: December 22, 1999
• Patent Grant Date: October 1, 2002
• Patent Term Adjustment (PTA) / Extension (PTE): There is no recorded Patent Term Adjustment or Extension for this patent. The time from filing to issuance was less than three years, and there are no other indications of statutory delays that would trigger a PTA.
• Projected Expiration: For utility patents filed after June 8, 1995, the term is 20 years from the earliest non-provisional filing date. Based on the filing date of December 22, 1999, the patent term expired on December 22, 2019.
• Current Status: The legal status of US Patent 6460050 is Expired.

Continuity and Application History

US Patent 6460050 issued from US application number 09/469,567. A review of the prosecution history and public records indicates:

• Continuation Applications: There are no continuation applications that claim priority to application 09/469,567.
• Divisional Applications: There are no divisional applications that claim priority to application 09/469,567.
• Continuation-in-Part Applications: There are no continuation-in-part applications that claim priority to application 09/469,567.

The patent is a standalone issuance from its original application and did not serve as the basis for a chain of subsequent U.S. patent applications.

Patent Family

The U.S. patent is part of a larger international patent family prosecuted through the Patent Cooperation Treaty (PCT). This indicates an initial intent to seek protection in multiple jurisdictions.

• PCT Application: A PCT application, PCT/US2000/042832, was filed on December 22, 2000, claiming priority to the original U.S. application. This was published as WO2001046872A1.
• Family Members: The PCT application led to the filing of several national and regional phase applications. Known family members include:
  • Australia: AU4525901A
  • Austria: ATE456098T1
  • Germany: DE60043746D1
  • Europe (EPO): EP1242921B1
  • Japan: JP4689921B2

The legal status of these foreign counterparts is listed as "Expired" or "IP Right Cessation" in public databases, which is consistent with the expiration of the priority U.S. patent.

Defensive Disclosure: Derivative Works and Obvious Implementations of Distributed Content Identification Systems

Publication Date: April 26, 2026
Subject: This document discloses foreseeable and obvious implementations, extensions, and applications of the core methods described in U.S. Patent 6460050, "Distributed content identification system." The purpose of this disclosure is to place these derivative concepts into the public domain, thereby establishing prior art against future patent applications claiming these incremental improvements.

1. Algorithmic & Component Substitution

1.1 Perceptual Hashing for Near-Duplicate Image and Video Detection

The core patent describes using cryptographic hashes (e.g., MD5) which are sensitive to single-bit changes. This disclosure extends the concept to perceptual hashing for identifying visually similar, but not identical, multimedia content.

Enabling Description: A client agent, upon encountering an image or video file, generates a perceptual hash (pHash). For an image, this involves resizing the image to a standard small size (e.g., 32x32 pixels), converting it to grayscale, applying a Discrete Cosine Transform (DCT) to the pixel matrix, retaining only the low-frequency components (e.g., the top-left 8x8 block), calculating the median DCT value, and generating a 64-bit hash where each bit represents whether the corresponding DCT value is above or below the median. This pHash is sent to the central server. The server, instead of checking for exact ID matches, calculates the Hamming distance between the submitted pHash and the pHashes in its database. A Hamming distance below a predetermined threshold (e.g., <= 5) indicates a visually similar image, which is then flagged. The same principle applies to video by sampling keyframes.

flowchart TD
    A[Client Agent receives Image/Video] --> B{Generate Perceptual Hash};
    B --> B1[Resize to 32x32];
    B1 --> B2[Convert to Grayscale];
    B2 --> B3[Apply DCT];
    B3 --> B4[Truncate to 8x8 Low-Frequency Components];
    B4 --> B5[Compute Median DCT Value];
    B5 --> B6[Generate 64-bit pHash based on Median];
    B6 --> C[Transmit pHash to Server];
    C --> D{Server receives pHash};
    D --> E[Query Database for pHashes with Hamming Distance <= 5];
    E --> F{Match Found?};
    F -- Yes --> G[Transmit 'Near-Duplicate' Characteristic to Client];
    F -- No --> H[Store pHash and Increment Appearance Count];
    G --> I[Client processes file based on reply];

1.2 Locality-Sensitive Hashing (LSH) for Document Similarity

This variation replaces the file-level cryptographic hash with Locality-Sensitive Hashing (LSH) to identify documents with substantial content overlap, even with rephrasing or minor edits.

Enabling Description: The client agent processes a text document by first converting it into a set of shingles (overlapping k-grams, e.g., 9-grams of words). From this set, it computes a MinHash signature, which is a compact representation of the document's content. This signature, which serves as the "digital ID," is sent to the server. The server utilizes a banding technique, where the MinHash signature is partitioned into several bands. If a new signature matches an existing signature in the database on at least one full band, the two documents are considered candidate pairs for a more detailed similarity check. This allows for sub-linear time similarity searches, making it highly scalable for large text corpora.

sequenceDiagram
    participant Client
    participant Server
    Client->>Client: Process Document into k-gram Shingles
    Client->>Client: Compute MinHash Signature from Shingles
    Client->>Server: Transmit MinHash Signature (ID)
    Server->>Server: Partition Signature into Bands
    Server->>Server: Query Database for Matching Bands
    alt Candidate Match Found
        Server-->>Client: Reply: 'High-Similarity Document'
    else No Match
        Server->>Server: Index Signature Bands in Database
        Server-->>Client: Reply: 'Unique Document'
    end

2. Operational Parameter Expansion

2.1 Edge-Native Implementation for IoT Anomaly Detection

The system is adapted to operate on resource-constrained IoT devices at the network edge to identify anomalous behavior across a fleet of sensors.

Enabling Description: An IoT device (e.g., a vibration sensor on an industrial motor) locally runs a lightweight agent. The agent continuously captures time-series sensor data. It uses a dimensionality reduction algorithm, such as Symbolic Aggregate Approximation (SAX), to convert a window of sensor readings (e.g., 1024 samples) into a short alphanumeric string (e.g., abacbabc). This string is the "digital ID" representing the motor's operational state. Under normal conditions, the agent does not transmit. If the generated ID deviates from a locally stored set of "normal" IDs, it is transmitted to a gateway. The gateway aggregates these anomaly IDs from thousands of devices and forwards them to a central server, which uses the frequency of specific anomalous IDs to identify systemic fleet-wide issues (e.g., a bad batch of bearings).

graph TD
    subgraph IoT Device
        A[Sensor Capture] --> B[SAX Transformation];
        B --> C{ID matches local normal profile?};
    end
    subgraph Edge Gateway
        D[Aggregate IDs] --> E[Forward to Cloud]
    end
    subgraph Cloud Server
        F[Correlate Fleet-wide IDs] --> G[Identify Systemic Anomaly]
    end
    C -- No --> D;
    E --> F;
    G --> H[Alert Operators];

2.2 Real-Time Stream Processing for Live Media Content Identification

The system is implemented for extreme low-latency, high-throughput environments such as identifying copyrighted content within user-generated live video streams.

Enabling Description: The client agent, integrated into a streaming server or client, samples video frames at a rate of 1 frame per second. For each frame, it uses a pre-trained convolutional neural network (CNN) to generate a feature vector (embedding) of a fixed size (e.g., 512 floating-point numbers). This vector is the "digital ID." These vectors are streamed via a high-throughput message queue (e.g., Apache Kafka) to a processing cluster. The server-side system uses a specialized vector database (e.g., Milvus or FAISS) that performs Approximate Nearest Neighbor (ANN) searches. It compares the incoming stream of vectors against a database of vectors from known copyrighted works in real-time. A match is flagged when the cosine similarity between an incoming vector and a database vector exceeds a threshold (e.g., 0.95).

sequenceDiagram
    participant StreamingClient
    participant ProcessingServer
    participant VectorDB
    loop Real-time
        StreamingClient->>StreamingClient: Sample video frame
        StreamingClient->>StreamingClient: Generate CNN feature vector (ID)
        StreamingClient->>ProcessingServer: Stream vector
        ProcessingServer->>VectorDB: Perform ANN search for vector
        VectorDB-->>ProcessingServer: Return nearest neighbors and similarity scores
        alt Similarity > 0.95
            ProcessingServer-->>StreamingClient: Send 'Content Match' notification
        end
    end

3. Cross-Domain Application

3.1 Genomic Sequence Variant Tracking

The system is applied to bioinformatics to enable a global, distributed network of labs to track the emergence and spread of specific genetic variants (e.g., viral mutations or antibiotic resistance genes).

Enabling Description: A sequencing lab's client agent takes a new genomic sequence (e.g., from a SARS-CoV-2 sample). It normalizes the sequence and applies a canonical hashing algorithm, such as ntHash, to a specific gene of interest (e.g., the Spike protein gene). The resulting hash is the "digital ID." This ID, along with anonymized metadata (timestamp, geographical region), is submitted to a central epidemiological server. The server aggregates these submissions globally. A sudden increase in the frequency of a new, previously unseen hash from multiple regions indicates the rapid spread of a novel mutation, allowing for real-time public health monitoring without sharing the full, sensitive sequence data.

flowchart TD
    A[Multiple Sequencing Labs] --> B{Process Sample & Extract Gene Sequence};
    B --> C[Generate ntHash of Sequence];
    C --> D[Submit Hash + Anonymized Geo/Time Metadata];
    D --> E[Central Epidemiology Server];
    E --> F{Aggregate and Analyze Hash Frequencies};
    F --> G[Detect Emergence/Spread of New Variant Hash];
    G --> H[Publish Real-time Public Health Alerts];

3.2 Supply Chain Counterfeit Detection

The system is used in logistics to identify counterfeit products by analyzing unique physical characteristics.

Enabling Description: At a distribution center, a product is scanned using a high-resolution optical scanner that captures its unique, unclonable surface texture (e.g., the grain pattern of a paper label). A feature extraction algorithm generates a compact digital signature from this texture, creating a "digital ID" based on this physical unclonable function (PUF). This ID is sent from the client agent (at the scanner) to a central server. The first time an authentic product is scanned, its ID is registered. If the same ID is later seen at a different location or time than is logically possible according to the supply chain records, it is flagged as a potential clone or counterfeit.

stateDiagram-v2
    [*] --> Unseen
    Unseen --> Registered: First scan (product induction)
    Registered --> In_Transit: Scanned at logistics hub
    In_Transit --> Delivered: Scanned at retail
    Delivered --> Flagged_Counterfeit: Second scan of same ID at another location
    In_Transit --> Flagged_Counterfeit: Second scan of same ID at another location
    state Fork <<fork>>
    Registered --> Fork
    Fork --> Flagged_Theft: Product never arrives at next hub
    Fork --> In_Transit

4. Integration with Emerging Technologies

4.1 AI-Driven Polymorphic Threat Detection

The system is integrated with machine learning to identify not just identical content, but entire "campaigns" of similar-but-not-identical malicious content (e.g., polymorphic malware or spam).

Enabling Description: Client agents generate and submit digital IDs (hashes) as in the base patent. The server, however, does not merely count frequencies. It uses a technique like SimHash, which produces hashes where the Hamming distance is proportional to the edit distance of the source files. The server constructs a massive graph where each hash is a node. An edge is created between two nodes if their Hamming distance is small. A graph neural network (GNN) is trained on this data to identify dense clusters of nodes, which represent a polymorphic campaign. When a new hash is submitted, the system checks if it connects to a known malicious cluster, allowing it to proactively block new variants of an attack.

classDiagram
    class Server {
        +receiveHash(hash)
        +findSimilarHashes(hash)
        +updateGraph(hash, similarHashes)
        +classifyCluster(cluster)
    }
    class GraphModel {
        -GNN_Classifier
        +isMalicious(cluster)
    }
    class HashNode {
        <<Node>>
        string hashValue
        int frequency
    }
    class SimilarityEdge {
        <<Edge>>
        int hammingDistance
    }
    Server --> GraphModel : Uses
    Server "1" -- "many" HashNode : Manages
    HashNode "1" -- "0..*" SimilarityEdge : has
    HashNode "1" -- "0..*" SimilarityEdge : has

4.2 Blockchain-based Decentralized Reputation System

The central server and database are replaced with a public blockchain and a smart contract, creating a trustless and censorship-resistant content identification system.

Enabling Description: Client agents are configured as blockchain clients (e.g., Ethereum nodes). When a client wants to check or report a file, it interacts with a smart contract. To report a file, the agent computes its hash and calls a reportHash(bytes32 fileHash) function in the contract. This function logs the hash and the reporter's address. To check a file, the agent calls a getReputation(bytes32 fileHash) function, which returns the number of unique addresses that have reported that hash. A file is considered malicious if its report count exceeds a threshold. Users can stake cryptocurrency to increase the weight of their reports, creating a decentralized web-of-trust.

sequenceDiagram
    participant UserAgent
    participant SmartContract
    participant Blockchain
    UserAgent->>UserAgent: Compute Hash of File
    UserAgent->>SmartContract: call reportHash(fileHash)
    SmartContract->>Blockchain: Record Hash and UserAgent's Address
    Blockchain-->>SmartContract: Transaction Confirmed
    SmartContract-->>UserAgent: Report Successful

    UserAgent->>SmartContract: call getReputation(fileHash)
    SmartContract->>Blockchain: Read Report Count for Hash
    Blockchain-->>SmartContract: Return Count
    SmartContract-->>UserAgent: Reputation Score (Count)

5. The "Inverse" or Failure Mode

5.1 Distributed Fallback via Gossip Protocol

The system is designed to fail gracefully. If the central characteristic server becomes unreachable, the client agents dynamically switch from a client-server model to a peer-to-peer (P2P) network.

Enabling Description: A client agent periodically sends a heartbeat to the central server. If the heartbeat fails for a specified duration (e.g., 60 seconds), the agent enters "decentralized mode." In this mode, it connects to a set of pre-configured or discovered peers. It uses a gossip protocol (e.g., SWIM) to exchange information about recently seen hashes and their local frequency counts. Each agent maintains a small, local bloom filter of high-frequency hashes reported by its peers. While less accurate than the central server, this allows the system to continue providing a baseline level of protection against widespread threats during a central outage. When the server becomes available again, the agents switch back to centralized mode.

stateDiagram-v2
    [*] --> Centralized_Mode
    Centralized_Mode --> Centralized_Mode: Heartbeat OK
    Centralized_Mode --> Decentralized_Mode: Heartbeat Fail
    Decentralized_Mode --> Centralized_Mode: Heartbeat Recovered
    Decentralized_Mode --> Decentralized_Mode: Gossip with Peers

6. Combination Prior Art Scenarios

6.1 Integration with SMTP via the Milter Protocol

The distributed content identification system is implemented as a mail filter (milter) that hooks into the open SMTP protocol standard used by mail servers like Sendmail and Postfix.

Enabling Description: A milter process is written in C and linked against the libmilter library. It registers callbacks for SMTP stages, specifically xxfi_eom (end of message). When the mail server receives a full email, the xxfi_eom callback is triggered. Inside this function, the milter computes the hash(es) of the message body and subject as described in the patent. It then makes a synchronous network call to the central ID server. If the server replies with a "spam" characteristic, the milter returns SMFIS_REJECT to the mail server, causing the SMTP transaction to be rejected with a 554 5.7.1 Message content rejected error before it is ever queued for local delivery.

6.2 Integration with the ClamAV Open Source Antivirus Engine

The system's logic is integrated as a custom signature type within the open-source ClamAV antivirus engine, allowing it to leverage ClamAV's widespread deployment for data collection.

Enabling Description: A new signature type is defined in the ClamAV source code, e.g., ReputationCheck:Host:Port:Options. A custom database file (.crb - Clam Reputation Database) is created containing these directives. When the clamd scan daemon encounters a file, it checks for standard byte-based signatures. If none match, it checks for reputation directives. If one is found, a new function within the engine computes the file's MD5 hash and sends it in a UDP packet to the specified Host and Port. The function waits a short time for a reply. A reply indicating a malicious characteristic causes ClamAV to flag the file as if it had matched a traditional virus signature (e.g., Win.Trojan.Reputation-1).

6.3 Integration with Apache Kafka and KSQL for Stream Processing

The entire backend system is built on open-source distributed streaming standards, specifically using Apache Kafka as the data bus for high-volume ID ingestion and KSQL for real-time characteristic analysis.

Enabling Description: Client agents are configured as Kafka producers. They serialize the digital ID and client metadata into a JSON or Avro object and publish it to a Kafka topic named content-ids. The server-side logic is a persistent KSQL query running on a Kafka cluster. The query is defined as: CREATE TABLE spam_counts AS SELECT id, COUNT(*) as appearance_count FROM content_ids WINDOW TUMBLING (SIZE 30 MINUTE) GROUP BY id HAVING COUNT(*) > 100;. This continuously analyzes a 30-minute rolling window of IDs. Any ID seen more than 100 times is automatically published to a new spam_alerts topic. A separate microservice consumes from this topic to update the master characteristic database that client agents query.