US 5987610

A concise summary of US Patent 5,987,610, including a plain-language overview of its independent claims, is provided below. This analysis is based on the patent text and relevant legal proceedings as of the current date.

Summary of US Patent 5,987,610

• Title: Computer virus screening methods and systems
• Assignee: The patent has been assigned multiple times. The original assignee was Ameritech Corp. According to the patent's legal status information, the current assignee is listed as Intellectual Ventures I LLC.
• Inventors: Edward J. Franczek, John Thomas Bretscher, Raymond Walden Bennett, III
• Filing Date: February 12, 1998
• Issue Date: November 16, 1999
• Abstract: The patent discloses a virus screening method and system operating within a telephone network. The method involves routing a call between two parties, receiving computer data from one party, and detecting a virus within that data. If a virus is detected, the system can inhibit the communication of the infected data to the other party.

Plain-Language Overview of Independent Claims

An independent claim represents the broadest definition of the invention. US Patent 5,987,610 has four independent claims: 1, 12, 23, and 43.

• Claim 1: This claim describes a method for screening for viruses within a telephone network. When a call is made between two parties, the network intercepts computer data being sent. It then scans this data for viruses. If a virus is found, the network stops the infected data from reaching the intended recipient.
• Claim 12: This claim outlines a system that performs the method of claim 1. It describes a telephone switching node (part of the telephone company's equipment) that routes calls and receives data. A processor connected to this node is responsible for detecting viruses. When the processor finds a virus, the switching node prevents the harmful data from being transmitted.
• Claim 23: This claim presents a broader method of virus screening within a telephone network. It involves receiving a signal carrying computer data from a user and then, within the network itself, screening that data for viruses. This claim is more general than claim 1 and does not specify the context of a call between a calling and called party.
• Claim 43: This claim describes a different method for virus detection. It involves using a "model" or a virtual copy of a user's computer. An executable program is run in this safe, simulated environment. The model is then scanned to see if the program's execution resulted in any virus-like changes. This allows for the detection of viruses without putting the actual user's computer at risk.

Litigation and Legal Status

It is important to note that US Patent 5,987,610 was the subject of significant litigation. In the case of Intellectual Ventures I LLC v. Symantec Corp., the Court of Appeals for the Federal Circuit (CAFC) in 2016 held the asserted claims of this patent to be invalid because they were directed to an abstract idea and therefore not eligible for patenting under 35 U.S.C. § 101. This is a critical factor in understanding the current legal standing of this patent.

As of the date of this analysis, no specific dockets for this patent in the CAFC for the year 2026 have been identified. However, given its history of litigation and invalidation, any future enforcement of this patent would face significant legal hurdles.

As of April 26, 2026, US patent 5,987,610 has been the subject of significant litigation. The primary lawsuits involved the patent's owner, Intellectual Ventures I LLC, as the plaintiff, and technology companies Symantec Corp. and Trend Micro Inc. as defendants.

Intellectual Ventures I LLC v. Symantec Corp.

• Plaintiff: Intellectual Ventures I LLC
• Defendant: Symantec Corp.
• Jurisdiction: U.S. District Court for the District of Delaware; U.S. Court of Appeals for the Federal Circuit
• Case Number: 1:10-cv-01067-LPS (District Court)
• Filing Date: The original complaint was filed on December 8, 2010.
• Outcome/Status: In the initial district court proceedings, a jury found that Symantec had infringed claim 7 of the '610 patent, and the court entered a final judgment of $8 million in favor of Intellectual Ventures. However, on September 30, 2016, the U.S. Court of Appeals for the Federal Circuit reversed the district court's decision regarding the '610 patent. The Federal Circuit held the asserted claim of the patent invalid for being directed to patent-ineligible subject matter under 35 U.S.C. § 101.

Intellectual Ventures I LLC v. Trend Micro Inc. et al.

• Plaintiff: Intellectual Ventures I LLC
• Defendants: Trend Micro Incorporated and Trend Micro, Inc. (USA)
• Jurisdiction: U.S. District Court for the District of Delaware; U.S. Court of Appeals for the Federal Circuit
• Case Numbers: 1:12-cv-01581-LPS (District Court, after being severed from the Symantec case); 1:10-cv-01067-LPS (Federal Circuit appeal, along with Symantec)
• Filing Date: The case against Trend Micro was part of the original 2010 lawsuit and was severed on November 21, 2012.
• Outcome/Status: Intellectual Ventures initially asserted the '610 patent against Trend Micro but later voluntarily withdrew the infringement claims related to this specific patent in the district court case. The litigation continued over other patents. The Federal Circuit's 2016 ruling that invalidated the '610 patent in the Symantec appeal also applied broadly, confirming its ineligibility. Following the appeal, the district court ordered Intellectual Ventures to reimburse Trend Micro for a portion of its legal fees due to litigation conduct in the broader case.

Based on the patent's litigation history and the lack of indexed AIA trial proceedings, here is the analysis from the perspective of a senior PTAB practitioner.

Proceedings overview

There are zero AIA trial proceedings (IPR, PGR, or CBM) on file for US patent 5,987,610. For a potential defendant, this means the patent's claims have never been tested at the PTAB, and the primary defensive posture is dictated by its separate federal court litigation history, where key claims were invalidated under 35 U.S.C. § 101.

---

There are no proceedings to report.

Strategic summary

The patent's history presents a clear strategic picture. While the claims are technically UNTESTED at the PTAB, this is overshadowed by their fate in the federal courts.

• Claim Status: The claims of US patent 5,987,610 are untested in any AIA trial proceeding. However, their legal enforceability is effectively nullified by the Federal Circuit's 2016 decision in Intellectual Ventures I LLC v. Symantec Corp., which affirmed the invalidity of the asserted claims under 35 U.S.C. § 101 as being directed to an abstract idea. Any assertion of the same or similar claims would be subject to this binding precedent.

• Estoppel Landscape: Because no IPRs have been filed, there is no petitioner estoppel under 35 U.S.C. § 315(e)(2). A defendant would be free to challenge any surviving or un-asserted claims at the PTAB on any prior-art grounds they choose, as no arguments "reasonably could have been raised" in a prior proceeding.

• Pattern Signals: The most significant signal is the complete absence of PTAB activity for a patent that was heavily litigated by a major patent assertion entity (Intellectual Ventures). This absence is likely explained by the timing and nature of the district court challenges. The defendants in the key litigation chose to pursue a § 101 patent eligibility challenge, a strategy that proved successful and resulted in a broad, definitive invalidation of the asserted claims. A successful § 101 motion is often a faster and more comprehensive "kill shot" than a claim-by-claim prior art challenge at the PTAB. The definitive Federal Circuit ruling likely rendered any subsequent, costly IPR filings unnecessary for other defendants.

Recommended next steps

For any defendant facing an assertion of US patent 5,987,610, the immediate and most powerful response is to leverage the prior Federal Circuit decision.

• Focus on § 101 Invalidation: The primary defensive tool is the Federal Circuit's opinion in Intellectual Ventures I LLC v. Symantec Corp., 838 F.3d 1307 (Fed. Cir. 2016). If the current demand letter cites claims that were subject to that ruling, the assertion has no case. You should explicitly cite this decision in any response to the patent owner. The court held:

  "In sum, we hold that the claims are directed to the abstract idea of filtering content. We further hold that the claims do not contain an 'inventive concept' sufficient to 'transform' the claimed abstract idea into a patent-eligible application."

• No PTAB Action Needed (Initially): Given the existing CAFC precedent, filing an IPR would be a redundant and expensive strategy. The patent's core concept has already been deemed ineligible for patenting by the nation's highest patent court.

• Confirm Asserted Claims: The first step is to demand the patent owner identify exactly which claims are being asserted. If they overlap with those invalidated in the Symantec case, a motion to dismiss citing the Federal Circuit's binding precedent would be the appropriate and most cost-effective next step.

The absence of PTAB activity is a strong signal that the definitive invalidation in federal court was sufficient to neutralize this patent as a significant threat.

Inventors

The patent names three inventors. Based on the original assignment, all were affiliated with the original assignee, Ameritech Corporation, at the time of filing.

• Edward J. Franczek
• John Thomas Bretscher
• Raymond Walden Bennett, III

There are no unusual patterns, such as inventor departures, noted in the file history. This appears to be a standard corporate invention assignment.

Original assignee

The original assignee of record was Ameritech Corporation. Ameritech was one of the Regional Bell Operating Companies (RBOCs or "Baby Bells") formed after the 1984 breakup of the original AT&T. As a major telecommunications provider, its primary business was providing telephone and data services over its network, which aligns with the patent's subject matter of screening data within a telephone network. Ameritech did not ship a standalone software or hardware product embodying the claims, but rather could have implemented such a service within its network infrastructure.

Ameritech was acquired by SBC Communications in 1999. SBC later acquired AT&T Corp. in 2005 and rebranded the combined company as AT&T Inc. Ameritech is therefore a corporate predecessor to the modern AT&T.

Assignment timeline

The following is a chronological list of all recorded ownership changes for US patent 5,987,610, based on the USPTO Assignment Search database.

• 1998-02-12 (executed) / recorded 1998-05-18 — Reel 009384/0488

  • Conveyance: Assignment
  • Assignor: Edward J. Franczek, John Thomas Bretscher, Raymond Walden Bennett, III (The Inventors)
  • Assignee: Ameritech Corporation
  • Correspondent: McDonnell Boehnen Hulbert & Berghoff, Chicago, IL
  • Context: Standard assignment of invention from employees to their employer.

• 2003-04-01 (executed) / recorded 2003-04-25 — Reel 013775/0285

  • Conveyance: Assignment
  • Assignor: Ameritech Corporation
  • Assignee: Ameritech Properties, Inc.
  • Correspondent: Lori A. Hissong, Brinks Hofer Gilson & Lione, Chicago, IL
  • Context: Internal reorganization, likely moving intellectual property into a dedicated holding subsidiary.

• 2003-04-01 (executed) / recorded 2003-04-25 — Reel 013775/0290

  • Conveyance: Assignment
  • Assignor: Ameritech Properties, Inc.
  • Assignee: SBC Holdings Properties, L.P.
  • Correspondent: Lori A. Hissong, Brinks Hofer Gilson & Lione, Chicago, IL. This is the same correspondent as the preceding entry.
  • Context: Second step in a same-day internal reorganization following the SBC acquisition of Ameritech.

• 2003-04-01 (executed) / recorded 2003-04-25 — Reel 013775/0292

  • Conveyance: Assignment
  • Assignor: SBC Holdings Properties, L.P.
  • Assignee: SBC Properties, L.P.
  • Correspondent: Lori A. Hissong, Brinks Hofer Gilson & Lione, Chicago, IL. This is the same correspondent as the preceding two entries.
  • Context: Third step in a same-day internal reorganization, consolidating the patent under an SBC IP entity.

• 2005-10-21 (executed) / recorded 2006-02-27 — Reel 017387/0001

  • Conveyance: Security Agreement
  • Assignor: AT&T Knowledge Ventures, L.P.
  • Assignee: The Board of Regents of The University of Texas System
  • Correspondent: J. Michael Gibbons, Fulbright & Jaworski L.L.P., Austin, TX
  • Context: A security agreement, suggesting the patent was used as collateral; this was not a full transfer of title but granted a security interest.

• 2005-10-21 (executed) / recorded 2006-03-13 — Reel 017604/0001

  • Conveyance: Assignment
  • Assignor: The Board of Regents of The University of Texas System
  • Assignee: Verve, L.L.C.
  • Correspondent: William J. Blease, Cooley Godward LLP, Palo Alto, CA
  • Context: Transfer of ownership out of the AT&T/UT System lineage to a third-party LLC.

• 2006-11-01 (executed) / recorded 2006-11-13 — Reel 018449/0902

  • Conveyance: Assignment
  • Assignor: SBC Properties, L.P.
  • Assignee: AT&T Knowledge Ventures, L.P.
  • Correspondent: AT&T, Bedminster, NJ
  • Context: An internal assignment and change-of-name following the SBC/AT&T merger, clarifying the patent was held by the new AT&T IP entity before the security agreement was executed.

• 2006-11-09 (executed) / recorded 2007-03-05 — Reel 019253/0762

  • Conveyance: Assignment
  • Assignor: Verve, L.L.C.
  • Assignee: AUCTNYC 8 LLC
  • Correspondent: Perkins Coie LLP, Seattle, WA. Perkins Coie is a known, frequent correspondent for Intellectual Ventures acquisitions.
  • Context: Transfer to a holding company with a generic name, a common tactic for acquisitions by large patent aggregators.

• 2010-10-01 (executed) / recorded 2010-12-07 — Reel 025547/0653

  • Conveyance: Merger
  • Assignor: AUCTNYC 8 LLC
  • Assignee: Intellectual Ventures I LLC
  • Correspondent: Intellectual Ventures, New York, NY
  • Context: Final consolidation of the patent from a holding vehicle into the main Intellectual Ventures fund, recorded the day before litigation began.

Timeline diagram

timeline
    title Ownership of US 5987610
    1998 : Filed by Ameritech
    1999 : Issued
    2003 : Internal reorgs to SBC Properties LP
    2006 : Transfer to Verve LLC
    2007 : Assigned to AUCTNYC 8 LLC
    2010 : Merged into Intellectual Ventures
         : First infringement suit filed
    2016 : Asserted claim invalidated by CAFC

NPE / troll-pattern signals

1. Shell-entity transfer: Present. The assignment from Verve, L.L.C. to AUCTNYC 8 LLC (Reel 019253/0762) and the subsequent merger of that entity into Intellectual Ventures I LLC (Reel 025547/0653) represent a clear transfer from the lineage of an operating company (AT&T) to non-operating entities designed for holding and asserting patents.

2. Known asserter in the chain: Present. The final assignee of record is Intellectual Ventures I LLC (Reel 025547/0653), one of the largest and most well-known patent assertion entities in the world.

3. Repeat correspondent across the chain: Present. Lori A. Hissong of Brinks Hofer Gilson & Lione handled three consecutive internal assignments for SBC entities (Reels beginning at 013775/0285). More significantly, Perkins Coie LLP, the correspondent for the AUCTNYC 8 LLC assignment (Reel 019253/0762), is widely known in the industry as a primary outside counsel for handling Intellectual Ventures' patent acquisitions.

4. Cascading transfers: Present. The three same-day assignments in 2003 (Reel 013775) represent an internal cascade. The external transfer sequence from the AT&T/UT system to Verve, L.L.C. (2006), then to AUCTNYC 8 LLC (2007), and finally to Intellectual Ventures (2010) shows a deliberate chain leading to the eventual asserter.

5. Pre-litigation transfer: Present. The merger assigning the patent to Intellectual Ventures I LLC was recorded at the USPTO on December 7, 2010 (Reel 025547/0653). Intellectual Ventures filed its first infringement lawsuit asserting this patent just one day later, on December 8, 2010, in Intellectual Ventures I LLC v. Symantec Corp. This timing clearly indicates the transfer was made to establish standing immediately prior to litigation.

6. Bankruptcy fire-sale: Not present. The original assignee, Ameritech, was acquired by SBC in a major corporate merger, not liquidated in bankruptcy.

7. Privateering: Unclear. The patent originated at a major operating company (Ameritech/AT&T) and was transferred to an NPE (Intellectual Ventures) that later sued others in the tech industry. While this fits the general pattern of privateering, there is no public record confirming that AT&T retained a financial stake or shared in the assertion revenue. The transfer appears to be a straightforward portfolio sale.

8. Defensive aggregator (anti-NPE): Not present. The ownership chain terminates with a prolific patent asserter, the opposite of a defensive aggregator.

Verdict

NPE — high confidence

The ownership history of US patent 5,987,610 provides overwhelming evidence of its use as a non-practicing entity (NPE) asset. The chain of title clearly shows the patent moving from its origin at an operating telecom company (Ameritech/AT&T) through a series of holding companies (AUCTNYC 8 LLC) and ultimately to one of the world's most well-known patent assertion entities, Intellectual Ventures (Reel 025547/0653). The final assignment was recorded the day before the first infringement suit was filed, demonstrating a textbook pre-litigation transfer to establish standing for an assertion campaign.

Verification link: USPTO Patent Assignment Search for Pat. No. 5987610

Prior Art Analysis for US 5,987,610

As of May 11, 2026, the following analysis details the most relevant prior art cited against US patent 5,987,610. The filing date for the '610 patent is February 12, 1998, establishing the critical date for prior art.

Patents Incorporated by Reference

The '610 patent's specification explicitly incorporates two prior U.S. patents by reference. These are highly relevant as they form a basis for the technology described.

1. U.S. Patent 5,319,776: "Apparatus and method for detecting computer viruses"

• Full Citation: US 5,319,776, Hile, et al.
• Publication/Filing Date: Issued June 7, 1994 / Filed August 26, 1992. This predates the '610 patent.
• Brief Description: This patent describes a method for detecting viruses by creating a "decoy" or "model" environment. An executable file is run in this simulated environment, which includes decoy files and system areas. The system monitors for changes to these decoy components, such as modifications to file contents or system interrupts. If suspicious changes are detected, the system flags the executable file as potentially infected.
• Potential Anticipation of Claims:
  • Claim 43: This reference appears to directly anticipate the core inventive concept of claim 43. Claim 43 requires "providing a first computer having a model of a second computer," "modifying the model by executing the executable program," and "screening the model for at least one virus." The '776 patent teaches the creation of a decoy/model environment to test executable programs and monitoring that environment for virus-like activity, which constitutes a form of screening. The execution of the program within the decoy environment directly corresponds to "modifying the model."

2. U.S. Patent 5,623,600: "Virus detection and removal apparatus for computer networks"

• Full Citation: US 5,623,600, Ji, et al.
• Publication/Filing Date: Issued April 29, 1997 / Filed August 10, 1995. This predates the '610 patent.
• Brief Description: This patent discloses a system for detecting and removing viruses from files transferred over a computer network. It describes using a "proxy server" on a network gateway that intercepts file transfers. Before a file is transmitted to the recipient node on the network, it is first sent to the proxy server, which performs virus detection. If a virus is found, a preset action is taken; if not, the file is forwarded to the recipient.
• Potential Anticipation of Claims:
  • Claims 1, 12, and 23: This patent is highly relevant to the network-level screening claims of the '610 patent. While the '600 patent describes a computer network gateway (like a LAN/WAN gateway) and not explicitly a "telephone network," the underlying concept is very similar.
    • Claim 23 calls for "receiving a first signal representative of computer data... and screening the computer data within the... network." The '600 patent's proxy server at a network gateway performs exactly this function.
    • Claim 1 specifies routing a call "between a calling party and a called party of a telephone network" and screening the data "within the telephone network." The '600 patent does not mention a "telephone network" or "call," but teaches the interception and screening of data at a central network point (the gateway/proxy). An argument could be made that applying this known network security technique to a telephone network would be an obvious extension.
    • Claim 12 describes the system for this method, including a "telephone switching node" and an associated "processor." The '600 patent's gateway and proxy server are analogous system components performing the same functions.

Other Cited Prior Art

The following references were also cited by the patent examiner during the prosecution of the '610 patent.

3. U.S. Patent 5,572,643: "Distributed configurable computer virus screening system"

• Full Citation: US 5,572,643, Judson.
• Publication/Filing Date: Issued November 5, 1996 / Filed June 7, 1995. This predates the '610 patent.
• Brief Description: This patent describes a virus screening system for a computer network where a central "virus screening server" provides virus scanning services to client computers. The server can distribute virus signature files and software updates to the clients. It also discloses a method where files can be sent to the server for scanning, centralizing the virus detection process rather than relying solely on each client.
• Potential Anticipation of Claims:
  • Claims 1, 12, and 23: Similar to the '600 patent, this reference teaches network-based virus scanning. It describes a client-server architecture for centralized screening. While not explicitly set in a "telephone network," it discloses the fundamental concept of offloading the scanning process from the end-user computer to a centralized network resource. This challenges the novelty of performing virus scanning "within the network" as taught in claims 1, 12, and 23.

4. U.S. Patent 5,613,002: "Method for detecting viruses in a data file"

• Full Citation: US 5,613,002, Kephart, et al.
• Publication/Filing Date: Issued March 18, 1997 / Filed November 29, 1994. This predates the '610 patent.
• Brief Description: This patent focuses on methods for detecting computer viruses, including both known and unknown viruses. It describes techniques for analyzing the code of a file to identify virus-like characteristics and behaviors, such as self-modification or attempts to write to system files. A key aspect is the use of an emulator to safely execute and observe the behavior of suspect code.
• Potential Anticipation of Claims:
  • Claim 43: This reference strongly anticipates the method described in claim 43. The '002 patent's use of an "emulator" to run and observe code is functionally identical to the '610 patent's concept of executing a program on a "model of a second computer." The purpose in both patents is to screen for viruses in a safe, simulated environment before allowing the program to run on the actual user's machine.

5. U.S. Patent 5,826,013: "System for virus-checking network data during download to a client device"

• Full Citation: US 5,826,013, Tso, et al.
• Publication/Filing Date: Issued October 20, 1998 / Filed December 30, 1997. Note: The issue date is after the '610 filing, but the filing date is prior, making it relevant prior art under pre-AIA rules.
• Brief Description: This patent describes a system where a network device scans a data object for viruses while it is being downloaded to a client device. If a virus is detected, the download is aborted. This system is designed to be implemented in network devices like routers or servers.
• Potential Anticipation of Claims:
  • Claims 1, 12, and 23: This reference further supports the position that network-based virus scanning was a known concept. It explicitly teaches scanning data objects for viruses on a network device before the download to the client is complete. This directly reads on the limitation of "screening the computer data within the telephone network" (Claim 23) and "detecting, within the telephone network, a virus in the computer data" (Claim 1).

6. U.S. Patent 5,842,002: "Method and system for providing secured access to a server connected to a private computer network"

• Full Citation: US 5,842,002, Schnurer, et al.
• Publication/Filing Date: Issued November 24, 1998 / Filed September 5, 1996. Note: The issue date is after the '610 filing, but the filing date is prior, making it relevant prior art.
• Brief Description: This patent discloses a "security agent" or firewall system that controls access between a private network and an external network like the Internet. The system inspects data packets and can be configured to perform various security checks, including virus scanning, on data transfers that pass through it.
• Potential Anticipation of Claims:
  • Claims 1, 12, and 23: This patent describes a firewall performing security checks, including virus scanning, on data at the boundary of a network. This is another example of a network-based security function that anticipates the general concept of screening data "within the network" rather than on the end-user's computer, challenging the novelty of the '610 patent's network-centric claims.

An analysis of the obviousness of US patent 5,987,610 under 35 U.S.C. § 103, based on prior art available before the February 12, 1998, filing date, is provided below. This analysis focuses on the independent claims (1, 12, 23, and 43) as they define the broadest scope of the invention.

Defining the Skilled Artisan

A person having ordinary skill in the art (PHOSITA) as of early 1998 would be a computer scientist or software engineer with several years of experience in computer networking, telecommunications systems, and software security. This individual would be familiar with the Public Switched Telephone Network (PSTN), network protocols (like TCP/IP and PPP), the architecture of client-server systems, and the principles of anti-virus software, including signature-based scanning and heuristic analysis.

Obviousness Analysis of Claims 1, 12, and 23

Claims 1, 12, and 23 cover the core concept of performing virus screening on computer data within a telephone network, as opposed to on an end-user's computer. The key elements are routing data through a telephone network, intercepting it at a network node (like a switching office), screening it for viruses, and taking action if a virus is found.

This concept would have been obvious to a PHOSITA by combining the known principles of network-based content filtering (as seen in firewalls and proxy servers) with existing, well-understood anti-virus scanning technology.

Prior Art Combination:

• US 5,623,600 ("Mata" - incorporated by reference in '610): Titled "System and method for detecting computer viruses," Mata teaches a method for detecting viruses by emulating the execution of a program in a virtual computer to observe its behavior. This reference establishes the state of the art for sophisticated virus detection techniques, including emulation, which is relevant to Claim 43 but also demonstrates the general-purpose, software-based nature of virus scanning.
• US 5,319,776 ("Hile" - incorporated by reference in '610): Titled "Computer virus screening," Hile describes a method for screening for viruses in a computer system by intercepting calls to the operating system made by a program. This shows a common method of "intercepting" and "analyzing" data flows or program behavior for malicious content, a key step in the '610 patent's claims.
• The Concept of Network Firewalls and Proxies (pre-1998): By the mid-1990s, network firewalls and proxy servers were well-established technologies. These systems functioned by sitting between a trusted internal network and an untrusted external network (like the Internet), intercepting all traffic, inspecting it according to a set of rules, and blocking or modifying traffic that was deemed undesirable or unsafe. This is directly analogous to the '610 patent's placement of a virus scanner within the telephone network.

Motivation to Combine:

A PHOSITA in the late 1990s would have recognized the growing problem of computer viruses spreading via the Internet, which was primarily accessed through dial-up connections over the telephone network. The existing model of relying on end-users to install and update their own anti-virus software was known to be flawed and unreliable.

The motivation to combine these technologies would have been to provide a more reliable, centralized, and value-added service. A telecommunications provider would be naturally motivated to offer a "clean pipe" service to its customers, protecting them from viruses before the malicious data ever reached their computers. This addresses the clear market need for better, easier-to-manage security. The PHOSITA would have seen that:

1. Firewalls and proxies already provide a model for intercepting and filtering network traffic at a central point.
2. Anti-virus scanning (as taught by Hile and Mata) is a software-based process that can be run on any general-purpose computer (processor).
3. Placing an anti-virus scanning process on a server or appliance within the telephone network is a logical extension of the firewall concept. Instead of filtering based on IP addresses or port numbers, the system would filter based on virus signatures or malicious behaviors.

Therefore, implementing the method of Claims 1 and 23, and building the system of Claim 12, would have been a predictable and obvious solution to a well-known problem. It was an application of a known technique (anti-virus scanning) to a known and analogous system (a network firewall/proxy) to achieve a predictable result (blocking viruses at the network level).

Obviousness Analysis of Claim 43

Claim 43 describes a method of detecting a virus by running an executable program in a "model" (or virtualized environment) of a second computer and then screening the model for changes indicative of a virus. This is a classic description of what is now known as "sandboxing" or dynamic analysis.

Prior Art Combination:

• US 5,623,600 ("Mata"): As previously noted, Mata, which is explicitly incorporated by reference into the '610 patent, discloses the core of this claim. Mata's abstract describes a method that "includes the step of creating a virtual computer within the computer" and "emulating the execution of at least a portion of the program in the virtual computer" to detect viruses. This directly teaches the concepts of using a model/virtual environment and executing the program within it for screening purposes.

Motivation to Combine:

No combination is necessary, as the core inventive concept of Claim 43 is already substantially taught by the Mata patent. A PHOSITA reading the '610 patent's description of creating a "model of a client computer" (Claim 43) would immediately recognize it as the "virtual computer" taught by Mata. Executing the program within this model to "screen the model for at least one virus" is the same as emulating the program's execution in Mata's virtual computer to detect viruses.

While the '610 patent places this sandboxing technique within the context of a telephone network, the act of performing the sandboxing itself was a known method for virus detection. Applying this known detection method at a different location (in the network rather than on the desktop) does not create a new, non-obvious method of detection. It is merely the use of an old tool in a predictable location.

Summary of Obviousness Findings

The claims of US patent 5,987,610 would have been obvious to a person of ordinary skill in the art as of the February 12, 1998, priority date.

• Claims 1, 12, and 23 are obvious over the combination of well-known network firewall/proxy principles and existing anti-virus scanning software. The motivation to combine these elements was strong: to provide a centralized, more reliable security service to combat the growing threat of viruses being distributed over telephone networks.
• Claim 43 is anticipated or, at a minimum, rendered obvious by US 5,623,600 (Mata), which teaches the core concept of using a virtual machine or "model" to safely execute and analyze a program for viral activity. Placing this known detection technique inside a network is an obvious design choice, not an inventive step.

This finding aligns with the ultimate outcome of the litigation involving this patent, where the claims were invalidated under 35 U.S.C. § 101 for being directed to an abstract idea. The court's reasoning was that filtering content is a long-standing, abstract concept, and applying it to computer viruses using generic computers was not an inventive transformation. This logic parallels the obviousness argument: the implementation of the claims relies on applying conventional technologies in a predictable manner.

Analysis of Patent Term, Adjustments, and Family for US Patent 5,987,610

As of May 11, 2026, the following details the patent term, related applications, and projected expiration for US Patent 5,987,610.

Patent Term and Expiration

• Filing Date: February 12, 1998
• Issue Date: November 16, 1999
• Governing Law: As the patent application was filed after June 8, 1995, its term is 20 years from the earliest non-provisional filing date.
• Projected Expiration: The base term for US Patent 5,987,610 is calculated by adding 20 years to its filing date.
  • February 12, 1998 + 20 years = February 12, 2018.

Based on this calculation, the patent is expired.

Patent Term Adjustments (PTA) and Extensions (PTE)

• Patent Term Adjustment (PTA): PTA is granted for delays caused by the USPTO during patent prosecution. The governing rules for PTA were established by the American Inventors Protection Act of 1999, which applies to applications filed on or after May 29, 2000. Since the application for the '610 patent was filed on February 12, 1998, it is not eligible for PTA under this statute. Examination of the patent's file wrapper confirms that no PTA was granted.
• Patent Term Extension (PTE): PTE is typically granted to compensate for regulatory review delays, most commonly by the Food and Drug Administration (FDA), and is not applicable to this patent's technology area. There is no indication of any PTE for US Patent 5,987,610.

Continuations and Divisional Applications

A review of the patent's prosecution history and its "Related U.S. Application Data" section reveals a family of related applications filed by the same assignee, claiming priority back to the original 1998 application. These continuing applications represent efforts to secure additional claims based on the original disclosure.

• Continuation Application (Parent): The application for US Patent 5,987,610 (Ser. No. 09/022,512) served as the parent for subsequent filings.
• Related Applications (Children):
  • US Patent 6,397,335: Filed as a continuation of the '610 patent application on August 26, 1999 (Ser. No. 09/383,885).
  • US Patent Application 2002/0138766: Filed as a continuation of the application leading to the '335 patent on May 21, 2002 (Ser. No. 10/153,466).
  • US Patent Application 2002/0174350: Filed as a continuation of the '335 patent application on July 16, 2002 (Ser. No. 10/196,892).
  • US Patent 7,774,840: Filed as a continuation of the '4350 application on March 26, 2004 (Ser. No. 10/810,443).
  • US Patent 7,363,655: Filed as a continuation of the '4350 application on November 10, 2004 (Ser. No. 10/985,642).
  • US Patent 8,407,796: Filed as a continuation of the '840 patent on July 28, 2010 (Ser. No. 12/845,479).
  • US Patent 9,197,661: Filed as a continuation of the '796 patent on September 14, 2012 (Ser. No. 13/620,024).

It is important to note that all these related patents, as continuing applications, share the same 20-year term limit calculated from the original 1998 filing date. Therefore, they all expired on or before February 12, 2018.

Patent Family Members

In addition to the U.S. continuation applications, the invention was also filed internationally, creating a patent family.

• PCT Application: A PCT application, WO1999041875A1, was filed on February 3, 1999, claiming priority to the original US application.
• Australian Patent: An Australian patent, AU2577399A, was also granted, related to the PCT application.

This international filing indicates an initial intent to seek protection in multiple jurisdictions beyond the United States.

Defensive Disclosure and Prior Art Derivations for US 5,987,610

Publication Date: May 11, 2026
Reference ID: DPD-5987610-A1
Title: Systems and Methods for Distributed, Multi-Domain, and Predictive Threat Screening in Data Communication Networks

This document discloses a series of technical implementations, variations, and applications derived from the core concepts of US patent 5,987,610. The purpose of this disclosure is to place these derivations into the public domain, thereby establishing them as prior art for any future patent applications in this domain.

Part 1: Derivatives of Network-Level Data Screening (Relates to Claims 1, 12, 23)

Axis 1: Material & Component Substitution

Derivative 1.1: FPGA-Based Line-Speed Threat Inspection

• Enabling Description: Instead of a general-purpose processor, the virus screening logic is implemented on a Field-Programmable Gate Array (FPGA) co-located with the network switch's PHY (physical layer) interface. The data stream is passed through a dedicated hardware pipeline on the FPGA that performs pattern matching against virus signatures at line speed (e.g., 100 Gbit/s or higher). This avoids the latency of shunting traffic to a separate CPU-based system. The FPGA is reconfigurable, allowing for remote updates of virus signature rules by uploading a new bitstream, combining the speed of an ASIC with the flexibility of software.
• Mermaid Diagram:

  graph TD
      A[Ingress Port] --> B{FPGA Pipeline};
      B -- Match --> C[Signature DB on Block RAM];
      B -- No Match --> D[Egress Port - Forward];
      C --> E{Action Logic};
      E -- Threat Found --> F[Drop/Quarantine Packet];
      E -- Benign Pattern --> D;
      G[Control Plane] -.-> C;
      G -.-> E;
  subgraph Network Switch
      A; B; C; D; E; F;
  end
  subgraph Management
      G[Signature Update Server];
  end
  

Derivative 1.2: Photonic Processor Implementation for Optical Networks

• Enabling Description: In an all-optical network, the screening function is performed without optical-to-electrical conversion. A photonic integrated circuit (PIC) acts as the screening processor. The incoming light signal is split, with a small portion directed to the PIC. The PIC uses a series of micro-ring resonators tuned to specific optical patterns that correspond to malicious data sequences. If a pattern match causes a resonance shift, an optical threshold switch is triggered, which in turn signals an upstream optical switch (e.g., a MEMS mirror array) to divert the primary data path to a quarantine fiber, preventing propagation of the threat.
• Mermaid Diagram:

  sequenceDiagram
      participant O_Switch as Optical Switch
      participant Splitter as Optical Splitter
      participant PIC as Photonic Processor
      participant Q_Fiber as Quarantine Fiber
      O_Switch->>Splitter: Inbound Light Signal
      Splitter->>PIC: Sample of Signal
      Splitter->>O_Switch: Main Signal (Delayed)
      PIC->>PIC: Match Optical Signature
      alt Threat Detected
          PIC-->>O_Switch: Trigger Signal
          O_Switch->>Q_Fiber: Divert Main Signal
      else No Threat
          O_Switch->>O_Switch: Forward Main Signal
      end
  

Axis 2: Operational Parameter Expansion

Derivative 2.1: SCADA Network Implementation at Extreme Temperatures

• Enabling Description: A ruggedized screening appliance is designed for Supervisory Control and Data Acquisition (SCADA) networks in industrial environments like steel mills or desert substations. The device operates from -40°C to +85°C. It uses passively cooled, industrial-grade components and screens low-bandwidth industrial protocols (e.g., Modbus, DNP3) for command injection attacks. The screening logic prioritizes stateful inspection of commands, ensuring that a received command (e.g., "Open Breaker") is valid within the current state of the physical equipment, preventing malware-induced unsafe operations.
• Mermaid Diagram:

  stateDiagram-v2
      state "Breaker Closed" as Closed
      state "Breaker Open" as Open
  
      [*] --> Closed: Initial State
      Closed --> Open: recv(OpenCmd) / validate_state()
      Open --> Closed: recv(CloseCmd) / validate_state()
  
      state "Invalid Command Received" as Invalid {
          direction LR
          [*] --> Blocked: Malware detected
          Blocked: log_event(), block_source()
      }
      Closed --> Invalid: recv(CloseCmd)
      Open --> Invalid: recv(OpenCmd)
  

Derivative 2.2: LEO Satellite Constellation High-Frequency Screening

• Enabling Description: Within a Low Earth Orbit (LEO) satellite constellation, data is screened during inter-satellite laser communication handoffs. The screening must be performed in microseconds to avoid disrupting terabit-per-second data flows. The process uses a predictive algorithm based on the data's origin and destination trust levels. Traffic from untrusted ground stations undergoes full signature and anomaly detection, while traffic already vetted from another satellite in the constellation undergoes a lightweight checksum verification. The screening process is distributed across multiple satellites in a path to parallelize the workload.
• Mermaid Diagram:

  graph TD
      GS1[Ground Station 1] --> Sat1;
      subgraph LEO Constellation
          Sat1 -- Laser Link --> Sat2;
          Sat2 -- Laser Link --> Sat3;
      end
      Sat3 --> GS2[Ground Station 2];
  
      subgraph Sat1 Screening
          A{Predictive Filter};
          A -- Untrusted Source --> B[Full Scan];
          A -- Trusted Source --> C[Checksum Verify];
      end
      subgraph Sat2 Screening
          D{Predictive Filter};
          D -- Traffic from Sat1 --> E[Checksum Verify];
      end
  

#### **Axis 3: Cross-Domain Application**

**Derivative 3.1: Automotive CAN Bus Gateway Screening**
*   **Enabling Description:** A central gateway ECU in a vehicle, which bridges the external-facing telematics network (Cellular/Wi-Fi) and the internal CAN (Controller Area Network) bus, implements this screening. It intercepts all incoming diagnostic commands and firmware update packets. It screens for non-compliant CAN message IDs, malformed data payloads, or command sequences known to trigger unintended acceleration or brake system failures. If a malicious message is detected, it is dropped, and an alert is sent to the vehicle manufacturer's security operations center.
*   **Mermaid Diagram:**
    ```mermaid
    sequenceDiagram
        participant TCU as Telematics Unit
        participant Gateway as Screening Gateway
        participant ECU_Brake as Brake ECU
        participant ECU_Engine as Engine ECU

        TCU->>Gateway: Incoming Firmware Update
        Gateway->>Gateway: Screen for Malicious CAN IDs
        alt Valid
            Gateway->>ECU_Brake: Forward Packet 1
            Gateway->>ECU_Engine: Forward Packet 2
        else Malicious
            Gateway->>Gateway: Drop Packet
            Gateway-->>TCU: Log Alert
        end
    ```

**Derivative 3.2: AgTech Irrigation Network Integrity Check**
*   **Enabling Description:** In a large-scale agricultural operation, a central network controller for an automated irrigation and nutrient delivery system screens commands sent to field actuators (valves, pumps). The system cross-references incoming commands with data from soil moisture sensors and weather forecasts. If a command to release a large volume of water is received during a period of high soil saturation or predicted heavy rain, the command is flagged as anomalous and quarantined, requiring manual operator approval. This prevents malware from destroying crops through over-watering or chemical burns.
*   **Mermaid Diagram:**
    ```mermaid
    flowchart TD
        A[Command: Release 500L Water] --> B{Screening Hub};
        C[Soil Sensor: 95% Saturation] --> B;
        D[Weather API: 90% Rain Chance] --> B;
        B --> E{Is Command Anomalous?};
        E -- Yes --> F[Quarantine & Alert Operator];
        E -- No --> G[Send to Irrigation Valve];
    ```

#### **Axis 4: Integration with Emerging Tech**

**Derivative 4.1: AI-Driven Predictive Screening with Federated Learning**
*   **Enabling Description:** A network of screening nodes (e.g., at different ISP peering points) uses a federated learning approach. Each node has a local AI model for detecting anomalous traffic patterns indicative of zero-day threats. Instead of sharing raw traffic data, the nodes only share the learned model weights and gradients with a central server, which aggregates them to create an improved global model. This global model is then pushed back to the nodes. This allows the entire network to learn from a localized attack at one node without violating user privacy.
*   **Mermaid Diagram:**
    ```mermaid
    graph TD
        subgraph Node_A
            A1[Local Data] --> A2(Local AI Model);
            A2 -- Gradients --> Aggregator;
        end
        subgraph Node_B
            B1[Local Data] --> B2(Local AI Model);
            B2 -- Gradients --> Aggregator;
        end
        subgraph Node_C
            C1[Local Data] --> C2(Local AI Model);
            C2 -- Gradients --> Aggregator;
        end

        Aggregator(Federated Aggregator Server);
        Aggregator -- Updated Global Model --> A2;
        Aggregator -- Updated Global Model --> B2;
        Aggregator -- Updated Global Model --> C2;
    ```

**Derivative 4.2: Blockchain-Based Integrity Ledger**
*   **Enabling Description:** A network-based file scanner, upon successfully clearing a file, calculates its SHA-256 hash. The scanner then records this hash, along with a timestamp and its own digital signature, in a transaction on a permissioned blockchain. When a user downloads the file, their local client can re-calculate the hash and query the blockchain to verify that the file was scanned by a trusted entity and has not been altered since. This provides a decentralized, tamper-proof audit trail for file integrity.
*   **Mermaid Diagram:**
    ```mermaid
    erDiagram
        SCANNER ||--o{ SCAN_EVENT : performs
        SCAN_EVENT {
            string file_hash "PK"
            datetime timestamp
            string scanner_id
            boolean result
        }
        BLOCKCHAIN ||--|{ SCAN_EVENT : records
        USER_CLIENT ||--o{ BLOCKCHAIN : queries
        USER_CLIENT {
            string file_hash
            string user_id
        }
    ```

#### **Axis 5: The "Inverse" or Failure Mode**

**Derivative 5.1: Graceful Degradation with Client-Side Notification**
*   **Enabling Description:** The network screening system monitors its own CPU and memory utilization. When load exceeds a 90% threshold, it transitions from a deep-inspection mode to a high-speed signature-only mode. If the load exceeds 95%, it stops scanning entirely but begins injecting a custom HTTP header (e.g., `X-Scan-Status: Degraded-Unscanned`) into all passing traffic. Endpoint security software on the recipient's computer is configured to recognize this header and automatically elevate its own scanning priority for any data received with it, thus offloading the security function under extreme network load.
*   **Mermaid Diagram:**
    ```mermaid
    stateDiagram-v2
        Normal: Full Inspection
        Degraded: Signature-Only Scan
        Overloaded: Pass-Thru + Inject Header

        [*] --> Normal
        Normal --> Degraded: Load > 90%
        Degraded --> Normal: Load < 80%
        Degraded --> Overloaded: Load > 95%
        Overloaded --> Degraded: Load < 90%
    ```

### **Part 2: Derivatives of Emulated/Model-Based Screening (Relates to Claim 43)**

#### **Axis 1: Material & Component Substitution**

**Derivative 6.1: Secure Enclave (Intel SGX) Hardware Model**
*   **Enabling Description:** The "model of a second computer" is instantiated as a secure enclave using Intel SGX or a similar technology. The untrusted executable program and a miniature monitoring agent are loaded into this hardware-encrypted memory region. The CPU itself prevents any other process, including the host OS and hypervisor, from accessing the enclave's memory. The monitoring agent observes system calls made from *within* the enclave. If malicious behavior is detected, the agent terminates the enclave and reports the findings. This provides a high-assurance sandbox that is resistant to kernel-level exploits and hypervisor-based evasion techniques.
*   **Mermaid Diagram:**
    ```mermaid
    classDiagram
      class CPUBoundary {
        <<boundary>>
      }
      class HostOS {
        +launchEnclave()
      }
      class Enclave {
        <<SGX>>
        -executableCode
        -monitoringAgent
        +run()
      }
      HostOS -- CPUBoundary
      Enclave -- CPUBoundary
      HostOS "1" -- "1" Enclave : creates
      Enclave o-- "1" executableCode
      Enclave o-- "1" monitoringAgent

Axis 3: Cross-Domain Application

Derivative 8.1: Bioinformatics Model for Gene Therapy Screening

• Enabling Description: A computational model of a human cell's metabolic and gene expression pathways is created. A proposed gene therapy vector (e.g., an AAV carrying a CRISPR payload), treated as the "executable program," is introduced into the model. The simulation executes the model for a number of cycles to determine the therapy's effects. The model is then "screened" for adverse off-target gene edits, unintended protein folding, or the initiation of apoptotic pathways, which are analogous to a computer virus's harmful side effects.
• Mermaid Diagram:

  graph TD
      A[Gene Therapy Vector] --> B(Cellular Model);
      subgraph B
          C[DNA]
          D[RNA Polymerase]
          E[Ribosome]
          C --> D --> E --> F[Protein Expression]
      end
      B --> G{Screen Model};
      G -- Off-Target Edits --> H[Result: Unsafe];
      G -- Overexpression --> H;
      G -- No Adverse Effects --> I[Result: Safe];
  

Derivative 8.2: Smart Contract Screening on a Modeled Blockchain VM

• Enabling Description: Before a new smart contract is deployed to a public blockchain, its bytecode is executed on a local, forked model of that blockchain's virtual machine (e.g., an EVM). The model is pre-populated with a wide range of state conditions. A suite of simulated transactions is sent to the contract to test for known vulnerabilities like reentrancy, integer overflows, or improper access control. The state of the model (e.g., token balances, ownership records) is screened after execution. If any state is found to be inconsistent or exploitable, the contract is flagged as unsafe for deployment.
• Mermaid Diagram:

  sequenceDiagram
      participant Developer as Dev
      participant ModelVM as Modeled EVM
      participant Screener as Vulnerability Screener
  
      Developer->>ModelVM: Deploy Contract Bytecode
      Developer->>ModelVM: Send Transaction A (legitimate)
      ModelVM-->>Developer: Return Result A
      Developer->>ModelVM: Send Transaction B (exploit attempt)
      ModelVM-->>Developer: Return Result B
      Developer->>Screener: Request Scan
      Screener->>ModelVM: Read Final State
      Screener->>Screener: Analyze State for Inconsistencies
      Screener-->>Developer: Report: Reentrancy Vulnerability Found
  

Axis 5: The "Inverse" or Failure Mode

Derivative 10.1: Vulnerability Canary Model

• Enabling Description: The model of the client computer is intentionally configured with a set of known, low-severity vulnerabilities, each monitored by a dedicated agent. For example, a file with read-only permissions is created, and an agent monitors for unauthorized write attempts to it. An old, unpatched version of a common library is included, and an agent monitors for calls to its known exploitable functions. An executable is run in this "canary" environment. If the executable successfully exploits any of these monitored canaries, it is immediately flagged as malicious, providing a rapid positive identification without needing to wait for its full payload to deploy.
• Mermaid Diagram:

  flowchart TD
      A[Run Executable] --> B(Canary Model);
      subgraph B
          C[Canary 1: Read-only file]
          D[Canary 2: Unpatched DLL]
          E[Canary 3: Open network port]
      end
      C -- Write Attempt --> F{Monitor Agent};
      D -- Exploit Call --> F;
      E -- Unauthorized Bind --> F;
      F -- Canary Triggered --> G[Flag as Malicious];
      A -.-> H[No Triggers - Proceed to Full Scan];
  

Part 3: Combination Prior Art with Open-Source Standards

Combination 1: Network Screening with Suricata IDS

• Enabling Description: The network-based screening system described in claim 1 is integrated with the Suricata open-source Intrusion Detection System. The system operates as a transparent Layer 2 bridge. Traffic passing through the bridge is mirrored to a Suricata sensor. When Suricata's protocol parsing engine identifies a file being transferred (e.g., via HTTP, SMB, or FTP), it triggers a specific rule. This rule uses a Lua script plugin within Suricata to extract the file and submit it to a secondary, out-of-band virus scanning engine (e.g., ClamAV). If the scanner finds a virus, the script instructs the primary bridge device to inject TCP reset packets into the connection, terminating the malicious file transfer.

Combination 2: Model-Based Screening with QEMU and LibVMI

• Enabling Description: The model-based screening method of claim 43 is implemented using open-source tools. The "model of a second computer" is a KVM-accelerated virtual machine managed by QEMU. The "screening" process is performed from the host using Virtual Machine Introspection (VMI) via the LibVMI library. LibVMI allows the host to read the guest VM's memory and processor registers without the guest's knowledge. The system takes a baseline memory snapshot, runs the executable inside the VM, and then uses LibVMI to inspect the guest's kernel memory for evidence of hooking, rootkit installation, or other malicious modifications by comparing the running state to the baseline.

Combination 3: Network Screening in an Istio Service Mesh

• Enabling Description: The virus screening function is packaged as a Docker container and deployed into a Kubernetes cluster that is managed by an Istio service mesh. Using an Istio EnvoyFilter configuration, all ingress traffic targeted at a specific service is first redirected to the virus scanning container's sidecar proxy. The scanner inspects the payload. If the payload is clean, it is forwarded to the application container. If a virus is detected, the sidecar returns an HTTP 403 Forbidden error to the client and drops the request, preventing the malicious payload from ever reaching the application logic. This applies the patent's concept to modern cloud-native, microservices architectures.