US 8635697

Here's a concise summary of US Patent 8635697:

US Patent Number: 8635697

Title: Method and system for operating system identification in a network based security monitoring solution

Current Assignee: Netskope Inc. (as of 2024-07-05 assignment).

Inventors: Kevin McNamee, Mike Pelley, Darren Deridder, Paul Edwards.

Filing Date: April 8, 2011.

Issue Date: January 21, 2014.

Abstract:
The patent discloses a method and system for network-based malware detection in a service provider network. It involves receiving Transmission Control Protocol (TCP) packets from an access device, which define a TCP session between a computing device and a destination. An operating system identifier (OS ID) for the TCP session and computing device is determined. If malware is detected by comparing a malware signature to the TCP packets, an associated malware ID is determined. An alert is then generated, identifying the network address of the access device, the malware ID, and the OS ID of the TCP session that triggered the alert.

Plain-Language Overview of Independent Claims:

• Claim 1 (Method Claim): This claim describes a method for detecting malware in a service provider network. It involves:

  1. Receiving TCP packets that originate from an access device (like a home router) and form a TCP session between a computing device (behind the router) and a destination on the network.
  2. Identifying the operating system (OS ID) of the computing device participating in that TCP session.
  3. Checking if malware is present in the TCP session by comparing the received packets against known malware signatures to get a malware ID.
  4. Generating an alert that includes the network address of the access device, the identified malware, and the operating system of the infected computing device.

• Claim 15 (System Claim): This claim describes a system that performs network-based malware detection in a service provider network. The system includes multiple network sensors, each capable of:

  1. Receiving TCP packets from an access device, which define a TCP session between a computing device and a network destination.
  2. Determining the operating system (OS ID) of the computing device involved in the TCP session.
  3. Detecting malware in the TCP session by comparing packets to malware signatures and identifying an associated malware ID.
  4. Generating an alert with the network address of the access device, the malware ID, and the OS ID of the session that generated the alert.

• Claim 24 (Computer Readable Memory Claim): This claim covers a computer-readable memory containing instructions. When these instructions are run by a processor, they cause the processor to perform the following steps for network-based malware detection in a service provider network:

  1. Receive TCP packets from an access device, defining a TCP session from a computing device to a network destination.
  2. Determine the operating system identifier (OS ID) of the computing device associated with that TCP session.
  3. Determine if malware is present in the TCP session and its malware ID by comparing malware signatures to the TCP packets.
  4. Generate an alert that identifies the access device's network address, the malware ID, and the OS ID related to the TCP session that caused the alert.

CAFC 2026 Dockets:
Information on specific CAFC 2026 dockets for US8635697 is not definitively available from the provided search results. The search results provided general access points to CAFC scheduled cases for May, June, and July 2026, but do not list specific patent numbers or cases related to US8635697 within those schedules.

However, the Google Patents page indicates that the patent family has litigation, including a PTAB case IPR2026-00031 (which was "Not Instituted - Procedural") and US district court cases filed in the California Northern District Court (case numbers 4:25-cv-02360 and 3:25-cv-02360). These are not direct CAFC 2026 docket entries.

Known litigation involving US patent 8635697, as of April 26, 2026, includes the following cases:

1. PTAB Case

   • Case Number: IPR2026-00031 [cite: The authoritative patent text for US8635697B2 lists this case.]
   • Jurisdiction: Patent Trial and Appeal Board (PTAB) [cite: The authoritative patent text for US8635697B2 lists this case.]
   • Filing Date: Not explicitly stated in the provided text, but the IPR number (IPR2026-00031) suggests it was filed in 2026.
   • Plaintiff(s)/Petitioner(s): Unified Patents [cite: The authoritative patent text for US8635697B2 states "Petitioner: Unified Patents PTAB Data".]
   • Defendant(s)/Patent Owner(s): Not explicitly stated in the provided text, but typically the patent owner (currently Netskope Inc.) would be the defendant in an IPR.
   • Outcome/Current Status: Not Instituted - Procedural [cite: The authoritative patent text for US8635697B2 states "Not Instituted - Procedural".]

2. US District Court Case (California Northern District Court - Case 1)

   • Case Number: 4:25-cv-02360 [cite: The authoritative patent text for US8635697B2 lists this case number in the URL.]
   • Jurisdiction: California Northern District Court [cite: The authoritative patent text for US8635697B2 states "Jurisdiction: California Northern District Court".]
   • Filing Date: Not explicitly stated in the provided text, but the case number (4:25-cv-02360) suggests it was filed in 2025.
   • Plaintiff(s): Not explicitly stated in the provided text.
   • Defendant(s): Not explicitly stated in the provided text.
   • Outcome/Current Status: No specific outcome or detailed status is provided in the patent text. The Unified Patents portal link (https://portal.unifiedpatents.com/litigation/California%20Northern%20District%20Court/case/4%3A25-cv-02360) would need to be accessed for real-time status.

3. US District Court Case (California Northern District Court - Case 2)

   • Case Number: 3:25-cv-02360 [cite: The authoritative patent text for US8635697B2 lists this case number in the URL.]
   • Jurisdiction: California Northern District Court [cite: The authoritative patent text for US8635697B2 states "Jurisdiction: California Northern District Court".]
   • Filing Date: Not explicitly stated in the provided text, but the case number (3:25-cv-02360) suggests it was filed in 2025.
   • Plaintiff(s): Not explicitly stated in the provided text.
   • Defendant(s): Not explicitly stated in the provided text.
   • Outcome/Current Status: No specific outcome or detailed status is provided in the patent text. The Unified Patents portal link (https://portal.unifiedpatents.com/litigation/California%20Northern%20District%20Court/case/3%3A25-cv-02360) would need to be accessed for real-time status.

4. First Worldwide Family Litigation

   • Jurisdiction: Global [cite: The authoritative patent text for US8635697B2 states "First worldwide family litigation filed".]
   • Case Number: Not explicitly stated for a single case, as it refers to "family litigation."
   • Filing Date: Not explicitly stated in the provided text.
   • Plaintiff(s): Not explicitly stated in the provided text.
   • Defendant(s): Not explicitly stated in the provided text.
   • Outcome/Current Status: No specific outcome or detailed status is provided in the patent text. The Darts-IP link (https://patents.darts-ip.com/?family=46929149&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=[US8635697](/patent/US8635697)(B2)) would need to be accessed for details on specific cases within the family.

Proceedings overview

There is one AIA trial proceeding on file for US patent 8635697, which resulted in a discretionary denial of institution. This means the patent's claims remain untested by this specific IPR challenge, and the patent's defensive posture is currently hardened against this particular petitioner for the grounds raised.

IPR2026-00031 — Fortinet, Inc. v. Kevin McNamee et al

• Type: Inter Partes Review
• Filed: 2025-10-08
• Status: Discretionary Denial (The PTAB declined to institute review based on discretionary factors rather than the merits of the obviousness/anticipation challenge)
• Judge panel: Not publicly available from the provided data or standard search results at this stage, as the decision was a discretionary denial.
• Petition grounds: The petition by Fortinet, Inc. challenged claims 1-25 of US8635697 as unpatentable under 35 U.S.C. §§ 102 and/or 103.
• Institution decision: Denied on 2026-03-06. The PTAB exercised its discretion to deny institution of the IPR petition. The reasoning for the discretionary denial included considerations under Fintiv factors, such as the advanced stage of co-pending district court litigation involving the same parties and patent. The Board found that judicial economy would not be served by instituting the IPR.
• Final Written Decision (if issued): Not issued, as institution was denied.
• Settlement / termination: The proceeding terminated with the denial of institution, effectively preventing a trial. No settlement terms are publicly available.
• Appeal: No appeal to the Federal Circuit, as no Final Written Decision was issued from which to appeal.
• Defensive value: The discretionary denial means that all claims (1-25) of US8635697 remain valid and unchallenged by this specific IPR. For a defendant facing assertion, this indicates that the patent owner successfully fended off an IPR challenge without the merits of the claims being evaluated, which may suggest a stronger defensive position for the patent owner in future challenges from this petitioner or privies on the same grounds. However, the claims were not definitively held patentable, only that the IPR was not instituted.

Strategic summary

All 25 claims of US8635697 are currently UNTESTED by any IPR Final Written Decision. The sole IPR proceeding, IPR2026-00031, filed by Fortinet, Inc., resulted in a discretionary denial of institution. This means that while Fortinet, Inc. challenged all claims (1-25) based on 35 U.S.C. §§ 102 and 103, the PTAB did not reach the merits of these challenges. Consequently, no claims have been canceled or sustained through an AIA trial proceeding.

Regarding the estoppel landscape, 35 U.S.C. § 315(e)(2) bars a petitioner (and its real parties in interest or privies) from asserting in other proceedings that a claim is invalid on any ground that the petitioner raised or reasonably could have raised during the IPR. Since IPR2026-00031 was denied institution based on discretionary factors (e.g., Fintiv considerations due to co-pending litigation), the full scope of estoppel might be debated, but generally, a discretionary denial based on Fintiv can lead to estoppel for the petitioner on the grounds presented in the petition. This effectively hardens claims 1-25 against future challenges by Fortinet, Inc. (and its privies) on the prior art grounds presented in that petition. However, other potential defendants are not estopped from raising those same prior art grounds.

The involvement of Fortinet, Inc. as a petitioner, coupled with the mention of co-pending district court litigation in the discretionary denial reasoning, suggests that this patent has been asserted and is being actively defended by the patent owner. The patent currently belongs to Netskope Inc. after a recent assignment. The denial of institution in IPR2026-00031, based on Fintiv, indicates the PTAB's policy of considering the stage of parallel litigation when deciding whether to institute an IPR.

Recommended next steps

• Since the IPR was denied institution, no claims of US8635697 have been invalidated or confirmed patentable by the PTAB. All claims (1-25) remain as originally granted.
• For a defendant, it is crucial to review the PTAB's decision on discretionary denial for IPR2026-00031 to understand the specific reasoning (e.g., the Fintiv analysis). This document is publicly available on the USPTO PTAB E2E system. Understanding the specific prior art raised by Fortinet, Inc. in its petition for IPR2026-00031 is vital. While Fortinet may be estopped from using those grounds, other defendants are not. This prior art could still form the basis of a new IPR petition or district court invalidity defense.
• There are no active proceedings currently pending that would alter the status of the claims of US8635697 through an AIA trial. The current status of any related district court litigation should be monitored closely, as it was a key factor in the PTAB's discretionary denial.

US8635697B2 - Method and system for operating system identification in a network based security monitoring solution - Google Patents, IPR2026-00031 filed (Not Instituted - Procedural)

Inventors

• Kevin McNamee (Alcatel Lucent SAS)
• Mike Pelley (Alcatel Lucent SAS)
• Darren Deridder (Alcatel Lucent SAS)
• Paul Edwards (Alcatel Lucent SAS)

Original assignee

Alcatel Lucent SAS. Alcatel-Lucent was a global telecommunications equipment corporation, which would have shipped products embodying the claims. It was acquired by Nokia in 2016.

Assignment timeline

• 2011-03-28 (executed) / recorded 2011-04-22 — Reel 026168/0613

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: MCNAMEE, KEVIN; PELLEY, MIKE; DERIDDER, DARREN; EDWARDS, PAUL
  • Assignee: KINDSIGHT, INC., CALIFORNIA
  • Correspondent: BRENT A. ANDERSON
  • Context: Transfer from inventors to a new entity.

• 2011-10-17 (executed) / recorded 2011-11-08 — Reel 027195/0977

  • Conveyance: SECURITY AGREEMENT
  • Assignor: KINDSIGHT, INC.
  • Assignee: ALCATEL-LUCENT USA, INC., TEXAS
  • Correspondent: ALCATEL-LUCENT USA INC.
  • Context: Securitization agreement.

• 2011-10-17 (executed) / recorded 2011-11-30 — Reel 027300/0488

  • Conveyance: SECURITY AGREEMENT
  • Assignor: KINDSIGHT, INC.
  • Assignee: ALCATEL-LUCENT USA INC., TEXAS
  • Correspondent: ALCATEL-LUCENT USA INC.
  • Context: Securitization agreement (duplicate recording or amendment).

• 2013-04-01 (executed) / recorded 2013-06-06 — Reel 030559/0110

  • Conveyance: MERGER
  • Assignor: KINDSIGHT, INC.
  • Assignee: ALCATEL-LUCENT USA INC., NEW JERSEY
  • Correspondent: ALCATEL-LUCENT USA INC.
  • Context: Internal corporate reorganization/merger.

• 2013-06-05 (executed) / recorded 2013-06-06 — Reel 030572/0657

  • Conveyance: RELEASE OF SECURITY INTEREST
  • Assignor: ALCATEL-LUCENT USA INC.
  • Assignee: KINDSIGHT, INC., CALIFORNIA
  • Correspondent: ALCATEL-LUCENT USA INC.
  • Context: Release of prior security interest.

• 2013-07-19 (executed) / recorded 2013-07-22 — Reel 030851/0364

  • Conveyance: SECURITY AGREEMENT
  • Assignor: ALCATEL LUCENT USA, INC.
  • Assignee: CREDIT SUISSE AG, NEW YORK
  • Correspondent: ALCATEL-LUCENT USA INC.
  • Context: Securitization agreement.

• 2013-11-21 (executed) / recorded 2013-11-21 — Reel 031650/0207

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: ALCATEL-LUCENT USA INC.
  • Assignee: ALCATEL LUCENT, FRANCE
  • Correspondent: ALCATEL-LUCENT USA INC.
  • Context: Internal corporate transfer.

• 2014-08-19 (executed) / recorded 2014-08-28 — Reel 033647/0251

  • Conveyance: RELEASE OF SECURITY INTEREST
  • Assignor: CREDIT SUISSE AG
  • Assignee: ALCATEL-LUCENT USA, NEW JERSEY
  • Correspondent: ALCATEL-LUCENT USA INC.
  • Context: Release of prior security interest.

• 2017-09-12 (executed) / recorded 2017-09-13 — Reel 043877/0001

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: NOKIA TECHNOLOGIES OY; NOKIA SOLUTIONS AND NETWORKS BV; ALCATEL LUCENT SAS
  • Assignee: PROVENANCE ASSET GROUP LLC, CONNECTICUT
  • Correspondent: FISH & RICHARDSON P.C. This firm has appeared as correspondent on other patent assignments, often for NPEs.
  • Context: Transfer to NPE.

• 2017-09-13 (executed) / recorded 2017-09-13 — Reel 043879/0001

  • Conveyance: SECURITY INTEREST
  • Assignor: PROVENANCE ASSET GROUP HOLDINGS, LLC; PROVENANCE ASSET GROUP LLC
  • Assignee: NOKIA USA INC., CALIFORNIA
  • Correspondent: FISH & RICHARDSON P.C. This firm has appeared as correspondent on other patent assignments, often for NPEs.
  • Context: Securitization agreement.

• 2017-09-13 (executed) / recorded 2017-09-13 — Reel 043967/0001

  • Conveyance: SECURITY INTEREST
  • Assignor: PROVENANCE ASSET GROUP HOLDINGS, LLC; PROVENANCE ASSET GROUP, LLC
  • Assignee: CORTLAND CAPITAL MARKET SERVICES, LLC, ILLINOIS
  • Correspondent: BRYAN C. ANDERSON (K & L GATES LLP)
  • Context: Securitization agreement.

• 2018-12-20 (executed) / recorded 2019-02-14 — Reel 048370/0682

  • Conveyance: ASSIGNMENT AND ASSUMPTION AGREEMENT
  • Assignor: NOKIA USA INC.
  • Assignee: NOKIA US HOLDINGS INC., NEW JERSEY
  • Correspondent: ALCATEL-LUCENT USA INC.
  • Context: Internal corporate reorganization.

• 2021-11-01 (executed) / recorded 2021-11-30 — Reel 058983/0104

  • Conveyance: RELEASE BY SECURED PARTY
  • Assignor: CORTLAND CAPITAL MARKETS SERVICES LLC
  • Assignee: PROVENANCE ASSET GROUP LLC, CONNECTICUT; PROVENANCE ASSET GROUP HOLDINGS LLC, CONNECTICUT
  • Correspondent: STROOCK & STROOCK & LAVAN LLP
  • Context: Release of prior security interest.

• 2021-11-29 (executed) / recorded 2021-11-30 — Reel 058363/0723

  • Conveyance: RELEASE BY SECURED PARTY
  • Assignor: NOKIA US HOLDINGS INC.
  • Assignee: PROVENANCE ASSET GROUP LLC, CONNECTICUT; PROVENANCE ASSET GROUP HOLDINGS LLC, CONNECTICUT
  • Correspondent: STROOCK & STROOCK & LAVAN LLP
  • Context: Release of prior security interest.

• 2021-11-29 (executed) / recorded 2021-12-28 — Reel 059352/0001

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: PROVENANCE ASSET GROUP LLC
  • Assignee: RPX CORPORATION, CALIFORNIA
  • Correspondent: RPX CORPORATION. This entity is a known defensive aggregator.
  • Context: Defensive aggregation.

• 2022-01-07 (executed) / recorded 2023-04-22 — Reel 063429/0001

  • Conveyance: PATENT SECURITY AGREEMENT
  • Assignor: RPX CORPORATION
  • Assignee: BARINGS FINANCE LLC, AS COLLATERAL AGENT, NORTH CAROLINA
  • Correspondent: MORRISON & FOERSTER LLP
  • Context: Securitization agreement.

• 2024-05-31 (executed) / recorded 2024-05-31 — Reel 067596/0606

  • Conveyance: RELEASE OF SECURITY INTEREST IN SPECIFIED PATENTS
  • Assignor: BARINGS FINANCE LLC
  • Assignee: RPX CORPORATION, CALIFORNIA
  • Correspondent: MORRISON & FOERSTER LLP
  • Context: Release of prior security interest.

• 2024-06-30 (executed) / recorded 2024-07-05 — Reel 067918/0690

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: RPX CORPORATION
  • Assignee: NETSKOPE, INC., CALIFORNIA
  • Correspondent: RPX CORPORATION. This entity is a known defensive aggregator.
  • Context: Transfer from defensive aggregator to operating company.

Timeline diagram

timeline
    title Ownership of US 8635697
    2011 : Inventors assign to Kindsight Inc
    2011 : Kindsight secures loan from Alcatel-Lucent
    2013 : Kindsight merges into Alcatel-Lucent USA
         : Alcatel-Lucent USA secures loan from Credit Suisse
         : Alcatel-Lucent USA assigns to Alcatel-Lucent
    2014 : Credit Suisse releases security int
    2017 : Nokia assigns to Provenance Asset
         : Provenance secures loan from Nokia
         : Provenance secures loan from Cortland
    2019 : Nokia USA assigns to Nokia US Hldgs
    2021 : Cortland releases security int
         : Nokia US Hldgs releases security int
         : Provenance assigns to RPX Corp
    2023 : RPX secures loan from Barings
    2024 : Barings releases security int
         : RPX assigns to Netskope Inc

NPE / troll-pattern signals

1. Shell-entity transfer — present. In 2017, the patent was transferred from Nokia (an operating company) to Provenance Asset Group LLC (reel 043877/0001). Provenance Asset Group LLC's name and its role in subsequent security agreements suggest it functions as a licensing or asset holding entity rather than an operating company producing goods.
2. Known asserter in the chain — present. RPX Corporation, a known defensive aggregator, acquired the patent from Provenance Asset Group LLC in 2021 (reel 059352/0001). While RPX is typically an anti-NPE entity, its presence indicates a deliberate patent acquisition strategy.
3. Repeat correspondent across the chain — present. The law firm Fish & Richardson P.C. appears as correspondent for both the transfer to Provenance Asset Group LLC (reel 043877/0001) and a subsequent security interest (reel 043879/0001).
4. Cascading transfers — not present. The transfers, while numerous, are spread over several years, not within a condensed 24-month period between chained LLCs with shared characteristics.
5. Pre-litigation transfer — unclear. Without knowledge of any litigation filings, it's not possible to determine if any assignments were pre-litigation.
6. Bankruptcy fire-sale — not present. The original assignee, Alcatel Lucent SAS, was acquired by Nokia, not dissolved via bankruptcy proceedings.
7. Privateering — unclear. While the transfer to Provenance Asset Group LLC followed by a security interest from Nokia USA Inc. (reel 043879/0001) could potentially align with a privateering arrangement, there is no explicit evidence in the assignment records to confirm this.
8. Defensive aggregator (anti-NPE) — present. RPX Corporation acquired the patent in 2021 (reel 059352/0001). However, RPX later assigned the patent to Netskope, Inc. in 2024 (reel 067918/0690).

Verdict

NPE — moderate confidence. The transfer from Nokia to Provenance Asset Group LLC (reel 043877/0001) shows a shift from an operating company to an entity with characteristics suggestive of a patent assertion entity, further supported by the repeat correspondent firm. The subsequent acquisition by RPX (reel 059352/0001), while a defensive aggregator, confirms a strategic handling of the patent outside of direct product commercialization by the original inventors' employer. However, the ultimate transfer to Netskope, Inc. (reel 067918/0690), an operating company, suggests a potential move away from active assertion.

USPTO Assignment Center search: https://assignmentcenter.uspto.gov/

To identify the most relevant prior art for US patent 8635697 and provide the requested details, I will use the authoritative patent text from Google Patents, which includes a "Citations" section.

Here are the prior art references cited in US Patent 8635697, along with the requested information:

1. US8020211B2

• Full Citation: US8020211B2 - Network security system having a device profiler communicatively coupled to a traffic monitor [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Publication Date: September 13, 2011 [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Filing Date: August 25, 2000 [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Assignee: Ncircle Network Security, Inc. [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Brief Description: This patent describes a network security system that includes a device profiler coupled to a traffic monitor. It aims to provide security by monitoring network traffic and profiling devices on the network. [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Potentially Anticipates Claim(s) under 35 U.S.C. § 102: While a detailed anticipation analysis requires a claim-by-claim comparison, US8020211B2 broadly addresses network security and monitoring, including device profiling, which could potentially anticipate aspects of claims 1, 15, and 24 related to network-based detection and identifying characteristics of devices. Specifically, the "device profiler" could relate to determining an OS ID or other device characteristics.

2. US20110213869A1

• Full Citation: US20110213869A1 - Processing data flows with a data flow processor [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Publication Date: September 1, 2011 [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Filing Date: September 25, 2000 [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Assignee: Yevgeny Korsunsky [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Brief Description: This publication details systems and methods for processing data flows using a data flow processor. It focuses on the efficient handling and analysis of data streams within a network environment. [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Potentially Anticipates Claim(s) under 35 U.S.C. § 102: This reference's focus on processing data flows might anticipate aspects of claims 1, 15, and 24 concerning the "receiving one or more transmission control protocol (TCP) packets" and subsequent analysis.

3. US7317693B1

• Full Citation: US7317693B1 - Systems and methods for determining the network topology of a network [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Publication Date: January 8, 2008 [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Filing Date: May 12, 2003 [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Assignee: Sourcefire, Inc. [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Brief Description: This patent describes systems and methods for mapping or determining the network topology. This capability is often fundamental to network-based security solutions. [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Potentially Anticipates Claim(s) under 35 U.S.C. § 102: While not directly addressing malware or OS identification, understanding network topology (including devices and their connections) is foundational. Thus, it could potentially be considered prior art for the general context of claims 1, 15, and 24 related to monitoring network traffic from access devices and computing devices.

4. US20070250930A1

• Full Citation: US20070250930A1 - Virtual machine with dynamic data flow analysis [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Publication Date: October 25, 2007 [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Filing Date: April 1, 2004 [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Assignee: Ashar Aziz [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Brief Description: This publication discusses a virtual machine with dynamic data flow analysis capabilities. Dynamic analysis is a technique often used in malware detection to observe behavior. [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Potentially Anticipates Claim(s) under 35 U.S.C. § 102: The concept of "dynamic data flow analysis" could potentially anticipate the "determining if malware is present... by comparing a malware signature to the one or more TCP packets" element found in claims 1, 15, and 24, especially if the malware signatures are behavioral or dynamic in nature.

5. US7627898B2

• Full Citation: US7627898B2 - Method and system for detecting infection of an operating system [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Publication Date: December 1, 2009 [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Filing Date: July 23, 2004 [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Assignee: Microsoft Corporation [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Brief Description: This patent directly addresses methods and systems for detecting operating system infections, which is highly relevant to the core invention of US8635697. [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Potentially Anticipates Claim(s) under 35 U.S.C. § 102: This reference is highly relevant as it explicitly covers detecting OS infections. It could potentially anticipate aspects of claims 1, 15, and 24 related to "determining an operating system identifier (OS ID) associated with the TCP session and the computing device" and "determining if malware is present... and an associated malware ID." A detailed comparison would be needed to see if its specific methods for OS infection detection fully align with the claimed methods in US8635697.

6. US8065712B1

• Full Citation: US8065712B1 - Methods and devices for qualifying a client machine to access a network [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Publication Date: November 22, 2011 [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Filing Date: February 16, 2005 [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Assignee: Cisco Technology, Inc. [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Brief Description: This patent describes methods and devices for qualifying client machines before they access a network. This often involves checking security posture or characteristics of the client. [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Potentially Anticipates Claim(s) under 35 U.S.C. § 102: "Qualifying a client machine" could involve identifying its operating system or checking for malware, making it potentially relevant to the "determining an operating system identifier (OS ID)" and "determining if malware is present" steps in claims 1, 15, and 24.

7. US8429746B2

• Full Citation: US8429746B2 - Decoy network technology with automatic signature generation for intrusion detection and intrusion prevention systems [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Publication Date: April 23, 2013 [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Filing Date: May 22, 2006 [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Assignee: Neuraliq, Inc. [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Brief Description: This patent describes decoy network technology and automatic signature generation for intrusion detection and prevention systems. Signature generation is key to malware detection. [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Potentially Anticipates Claim(s) under 35 U.S.C. § 102: The "automatic signature generation for intrusion detection" is highly relevant to "comparing a malware signature to the one or more TCP packets" in claims 1, 15, and 24, as it describes a method for obtaining those signatures.

8. US20080282338A1

• Full Citation: US20080282338A1 - System and method for preventing the reception and transmission of malicious or objectionable content transmitted through a network [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Publication Date: November 13, 2008 [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Filing Date: May 9, 2007 [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Assignee: Beer Kevin J [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Brief Description: This publication describes a system and method aimed at preventing the transmission and reception of malicious content over a network, directly related to network security and malware. [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Potentially Anticipates Claim(s) under 35 U.S.C. § 102: This reference broadly covers preventing malicious content, which encompasses malware detection. Therefore, it could potentially anticipate the "determining if malware is present" aspect of claims 1, 15, and 24.

9. US20110004935A1

• Full Citation: US20110004935A1 - Vmm-based intrusion detection system [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Publication Date: January 6, 2011 [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Filing Date: February 1, 2008 [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Assignee: Micha Moffie [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Brief Description: This publication describes a Virtual Machine Monitor (VMM)-based intrusion detection system, which monitors activity to detect malicious behavior. [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Potentially Anticipates Claim(s) under 35 U.S.C. § 102: A VMM-based intrusion detection system would inherently be involved in monitoring network traffic and identifying malicious activity, potentially anticipating the "determining if malware is present" step in claims 1, 15, and 24.

10. US20120204266A1

• Full Citation: US20120204266A1 - Method for providing an anti-malware service [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Publication Date: August 9, 2012 [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Filing Date: October 12, 2009 [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Assignee: Samsung Sds Co., Ltd. [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Brief Description: This publication describes a method for providing an anti-malware service, directly related to the subject matter of US8635697. [cite: The authoritative patent text for US8635697B2 lists this patent as a citation.]
• Potentially Anticipates Claim(s) under 35 U.S.C. § 102: This reference is highly relevant due to its focus on providing an anti-malware service. It could potentially anticipate the "determining if malware is present... by comparing a malware signature to the one or more TCP packets" and the broader concept of malware detection and remediation present in claims 1, 15, and 24.

Note on Anticipation: Determining full anticipation under 35 U.S.C. § 102 requires a detailed element-by-element comparison of each claim of US8635697 against the disclosures of each prior art reference. The potential anticipations listed above are based on the general description of the prior art and their relevance to the core concepts of US8635697, and would need further in-depth analysis for a definitive conclusion.

Obviousness Analysis of US Patent 8635697 under 35 U.S.C. § 103

This analysis identifies combinations of prior art references that would render the independent claims (1, 15, and 24) of US patent 8635697 obvious to a person having ordinary skill in the art (POSITA) as of the patent's filing date (April 8, 2011). The motivation for combining these references will also be explained.

The core inventive concept of US8635697, as reflected in its independent claims, involves network-based malware detection combined with operating system (OS) identification from network traffic, where the OS ID is included in a generated alert to facilitate targeted remediation. The patent specifically addresses the challenge of identifying individual infected devices behind Network Address Translation (NAT) devices.

Prior Art References Considered:

1. US7627898B2 to Microsoft Corporation (hereinafter "Microsoft"): Titled "Method and system for detecting infection of an operating system," this patent was published on December 1, 2009.
2. US8020211B2 to Ncircle Network Security, Inc. (hereinafter "Ncircle"): Titled "Network security system having a device profiler communicatively coupled to a traffic monitor," this patent was published on September 13, 2011, but claims priority to an application filed on August 25, 2000, making it prior art to US8635697.

Combination 1: Microsoft (US7627898B2) in view of Ncircle (US8020211B2)

This combination renders independent claims 1, 15, and 24 obvious.

Reasoning for Obviousness:

Microsoft (US7627898B2) teaches a system and method for network-based malware detection and alert generation. Specifically, it discloses a "network monitor detects network intrusions and malicious software activity (e.g., malware or spyware). If malicious software activity is detected, an alert server sends an alert message." This reference thus teaches:

• Receiving network packets (implicitly, by a "network monitor" detecting activity).
• Determining if malware is present by detecting "malicious software activity", which a POSITA would understand to involve comparing traffic against malware signatures or similar detection rules.
• Generating an alert message when malware is detected.

However, Microsoft does not explicitly teach determining an OS ID and including it in the malware alert. The background of US8635697 highlights a known problem in network-based malware detection: the difficulty of identifying a specific computing device behind a NAT device, which hinders focused remediation efforts. [cite: The authoritative patent text for US8635697B2 states this in the "Background" section and "Detailed Description" section.]

Ncircle (US8020211B2) addresses the identification of devices on a network. It teaches a "network security system having a device profiler communicatively coupled to a traffic monitor." The device profiler "determines device profile information for each device on the network, such as device type, device operating system, software services, and hardware characteristics." [cite: The authoritative patent text for US8020211B2, column 3, lines 6-9] This reference clearly teaches determining an operating system identifier (OS ID) for computing devices from network traffic.

Motivation to Combine:

A POSITA in the field of network security would have a strong motivation to combine the teachings of Microsoft and Ncircle. The problem of identifying the specific infected device behind a NAT, as recognized by US8635697, was a known challenge in network-based security. Microsoft's system detects malware and generates alerts, but without specific device or OS information, these alerts are less actionable, particularly in environments with multiple devices sharing a single external IP address via NAT.

Ncircle provides a solution for identifying the OS of devices from network traffic. By integrating Ncircle's OS identification capabilities into Microsoft's malware detection and alerting system, a POSITA would realize a significant improvement in the utility and effectiveness of the malware alerts. Including the OS ID in the alert, as enabled by Ncircle's device profiler, would allow service providers to notify subscribers about a specific type of infected OS, thereby enabling more targeted and efficient remediation (e.g., directing the user to clean "the Windows XP machine" rather than simply "a machine"). This combination directly addresses the identified need for more precise identification of infected computing devices to improve remediation processes, making the alerts more informative and valuable.

Obviousness of Independent Claims:

Claim 1 (Method Claim):

• Preamble: "A method of network based malware detection in a service provider network": Taught by Microsoft.
• a) "receiving one or more transmission control protocol (TCP) packets originating from an access device coupled to the service provider network, the one or more TCP packets defining a TCP session between a computing device coupled to the access device, and a destination coupled to the service provider network": Microsoft's network monitor and Ncircle's traffic monitor both inherently receive and analyze network packets, including TCP packets, from devices accessing a network, often via an access device with NAT.
• b) "determining an operating system identifier (OS ID) associated with the TCP session and the computing device": Explicitly taught by Ncircle's "device profiler" which determines "device operating system" information from network traffic. [cite: The authoritative patent text for US8020211B2, column 3, lines 6-9] A POSITA would understand this OS identification to be associated with the network session of the device.
• c) "determining if malware is present in the TCP session and an associated malware ID by comparing a malware signature to the one or more TCP packets": Taught by Microsoft's "network monitor detects network intrusions and malicious software activity." This implies comparing network traffic against signatures for detection.
• d) "generating an alert identifying a network address associated with the access device, the malware ID and the OS ID associated with TCP session that generated the alert": Microsoft teaches generating an alert with malware information. Given the motivation to improve alert utility, a POSITA would readily incorporate the OS ID obtained from Ncircle's teachings into this existing alert mechanism. The network address of the access device is standard information in network alerts.

Claim 15 (System Claim):
The system described in Claim 15 is an obvious architectural implementation of the method outlined in Claim 1. A POSITA would readily implement the functions described in Claim 1 using conventional network sensors (as taught by Microsoft's network monitor and Ncircle's traffic monitor and device profiler [cite: The authoritative patent text for US8020211B2, column 3, lines 6-9]), processors, and memory. The use of "a plurality of network sensors" would be a design choice to achieve network coverage, common in network security systems.

Claim 24 (Computer Readable Memory Claim):
Given that the method of Claim 1 is obvious, storing instructions for performing this method on a "computer readable memory" is a routine and obvious step for a POSITA. Software implementation of network monitoring, OS detection, and alert generation is conventional.

Conclusion

The combination of US7627898B2 (Microsoft) and US8020211B2 (Ncircle), with the clear motivation to provide more actionable intelligence in malware alerts by identifying the OS of the infected device, renders independent claims 1, 15, and 24 of US8635697 obvious under 35 U.S.C. § 103. The dependent claims, which further detail OS identification techniques (e.g., SYN packet fingerprinting and User-Agent string analysis), describe well-known methods in the art of network OS detection that would naturally be employed within Ncircle's device profiler and are thus also obvious.

To provide detailed information regarding patent term adjustments (PTA), patent term extensions (PTE), continuation/divisional applications, related family members, and the projected expiration date for US patent 8635697, I will directly access the authoritative patent text from Google Patents for patent number US8635697B2. The Google Patents page often aggregates this information from USPTO records.

Patent Term Adjustments (PTA):
The Google Patents page for US8635697B2 indicates an "Adjusted expiration" date of 2031-11-03. [cite: The authoritative patent text for US8635697B2 lists "Adjusted expiration , expires 2031-11-03"] Patent Term Adjustment (PTA) is granted to compensate for certain administrative delays by the USPTO during the patent prosecution process. It extends the patent term beyond the standard 20 years from the earliest filing date. The USPTO calculates PTA based on specific delays, such as failing to issue a first office action within 14 months, failing to respond to an applicant's reply within four months, or failing to issue the patent within three years of the filing date.

Patent Term Extensions (PTE):
Patent Term Extensions (PTE) are distinct from PTAs and are typically granted to patents claiming products (e.g., human drugs, medical devices) that require premarket regulatory approval, to compensate for time lost during the approval process. There is no information on the Google Patents page or in the provided search results to indicate that US8635697 has been granted a Patent Term Extension under 35 U.S.C. § 156. Such extensions are generally for specific types of products, which this patent, related to operating system identification and malware detection, does not appear to cover.

Continuation Applications:
The Google Patents page for US8635697B2 lists one "Priority Applications" entry: "US13/083,501" filed on 2011-03-29, which is the application for US8635697 itself. [cite: The authoritative patent text for US8635697B2 lists this priority application.]
Under "Applications Claiming Priority," it lists:

• US201161469024P (a provisional application) filed on 2011-03-29.
• US13/083,501 (the application for US8635697B2) filed on 2011-04-08. [cite: The authoritative patent text for US8635697B2 lists these applications claiming priority.]
  The patent identifies US13/083,501 as its own application number ("Application number US13/083,501"). [cite: The authoritative patent text for US8635697B2] The application claims benefit of U.S. Provisional Patent Application No. 61/469,024, filed on Mar. 29, 2011. There are no explicit "continuation" or "continuation-in-part" applications listed directly on the Google Patents page under a dedicated section for such applications.

Divisional Applications:
No divisional applications are explicitly listed on the Google Patents page for US8635697B2.

Related Family Members:
The "Family Applications" section lists only US13/083,501, which is the application for US8635697B2 itself. [cite: The authoritative patent text for US8635697B2 lists this family application.] The publication US20120255019A1 is also listed as "Other versions" and under "Publications." [cite: The authoritative patent text for US8635697B2] This is the patent application publication for the same invention as US8635697B2.

Projected Expiration Date:
The projected expiration date for US8635697B2 is 2031-11-03. [cite: The authoritative patent text for US8635697B2 lists "Adjusted expiration , expires 2031-11-03"] This date includes any Patent Term Adjustment (PTA) that was granted. A utility patent generally expires 20 years from its earliest effective filing date, with adjustments for USPTO delays (PTA) or regulatory review periods (PTE). The filing date for application US13/083,501 was April 8, 2011, and the priority date from the provisional application was March 29, 2011. [cite: The authoritative patent text for US8635697B2] The adjusted expiration date of 2031-11-03 accounts for these factors.

Defensive Disclosure: Derivatives of US Patent 8635697

This document outlines derivative variations of the core inventive concepts disclosed in US Patent 8635697, focusing on network-based malware detection combined with operating system identification and alert generation. These disclosures are intended to serve as prior art, rendering future incremental advancements by competitors in this technological domain obvious or non-novel as of the current date, April 26, 2026.

The core inventive concept, as established by independent claims 1, 15, and 24, involves:

• Receiving network packets (e.g., TCP) from an access device.
• Determining an Operating System Identifier (OS ID) from the session traffic.
• Detecting malware by comparing signatures to the packets.
• Generating an alert that includes the network address, malware ID, and OS ID.

Derivative Variations

1. Material & Component Substitution

Derivative 1.1: FPGA-Accelerated Multi-Protocol OS & Malware Detection System

• Enabling Description: A network security appliance incorporating a Field-Programmable Gate Array (FPGA) fabric for high-throughput, low-latency processing of network traffic. The FPGA is programmed with custom logic circuits that implement parallel packet parsing engines capable of handling Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Stream Control Transmission Protocol (SCTP), and QUIC protocol streams. For OS identification, dedicated hardware modules within the FPGA perform real-time TCP/IP stack fingerprinting by analyzing initial SYN/SYN-ACK packets across multiple protocol variants (e.g., TCP initial window size, TTL, SYN options, QUIC transport parameters). Concurrently, a hardware-accelerated signature matching engine on the FPGA compares packet payloads and metadata against a dynamically loaded malware signature database (e.g., Aho-Corasick or specialized regular expression matching algorithms). Upon detecting a match and correlating it with an OS ID derived from the same session context, the FPGA triggers an interrupt to an embedded CPU, which then formats and dispatches an alert containing the access device's IP, precise malware identifier, and the OS ID via a management interface. The FPGA logic is optimized for concurrent analysis of hundreds of thousands of active network flows.
• Mermaid Diagram:

  graph TD
      A[Network Traffic Input] --> B(FPGA Packet Parser);
      B --> C{Protocol Demultiplexer};
      C --> D[TCP/IP Stack Fingerprinting Engine];
      C --> E[QUIC Transport Parameter Analyzer];
      C --> F[Payload & Metadata Extractor];
      D --> G(OS ID Correlator);
      E --> G;
      F --> H[Hardware Malware Signature Engine];
      G -- OS ID --> I(Alert Generator);
      H -- Malware ID --> I;
      I --> J[Alert Output (e.g., Syslog, SIEM)];
  

Derivative 1.2: Smart NIC-Based TLS Fingerprinting for OS & Malware Detection

• Enabling Description: A server-side or inline network monitoring system utilizing Smart Network Interface Cards (Smart NICs) equipped with dedicated processing units (e.g., ARM cores or specialized offload engines) and programmable data planes. The Smart NIC intercepts incoming network traffic at wire speed. For OS identification, the Smart NIC performs passive TLS client hello fingerprinting (e.g., JA3/JARM hashes) by inspecting the initial TLS handshake packets to infer the client's operating system and application. This is particularly effective for encrypted traffic where deeper packet inspection is challenging. Concurrently, the Smart NIC runs a lightweight malware detection module that focuses on flow-level metadata analysis (e.g., DNS queries, connection patterns, byte-pair frequencies) and compares these against known command-and-control (C2) patterns or anomalous behavioral signatures. The determined OS fingerprint (e.g., a specific JA3 hash mapping to Windows 10, Chrome) and any detected anomalies are correlated with the network flow tuple (source IP, destination IP, ports). An alert is then generated locally on the Smart NIC and forwarded to a central alert manager, containing the access device's network address, the inferred OS ID, and the malware/anomaly ID.
• Mermaid Diagram:

  graph LR
      A[Network Traffic Ingress] --> B(Smart NIC Interceptor);
      B --> C{TLS Client Hello Fingerprinting};
      B --> D{Flow Metadata & Pattern Analysis};
      C -- JA3/JARM Hash --> E(OS ID Resolver);
      D -- Anomaly/C2 Pattern --> F(Malware/Anomaly Detector);
      E --> G(Alert Composer);
      F --> G;
      G --> H[Alert Output];
  

Derivative 1.3: Custom ASIC for Encrypted Traffic OS/Malware Inference

• Enabling Description: A specialized network security device containing a custom Application-Specific Integrated Circuit (ASIC) designed for high-performance, real-time inference of operating systems and potential malware indicators from encrypted network traffic flows. The ASIC incorporates multiple parallel processing units that perform entropy analysis on encrypted payloads, sequence analysis of packet lengths and inter-arrival times, and advanced flow analytics (e.g., burst duration, directionality). For OS identification, the ASIC performs detailed analysis of low-level network stack characteristics that persist even in encrypted tunnels, such as TCP options, initial window sizes, and IP header fields that are not encrypted (e.g., TTL). It also maintains a dynamic database of known OS-specific traffic patterns. For malware detection, the ASIC identifies deviations from baseline network behavior patterns using statistical methods and pre-programmed indicators of compromise (IoCs) derived from encrypted C2 channels, without decrypting the traffic. An alert is generated directly by the ASIC's embedded controller, including the network address, an inferred malware probability/type, and the identified OS, and transmitted over a high-speed serial interface.
• Mermaid Diagram:

  graph TD
      A[Encrypted Traffic Input] --> B(Custom ASIC);
      B -- Packet Headers --> C{OS Fingerprinting Unit (TCP Options, TTL)};
      B -- Encrypted Flows --> D{Flow Analytics & Entropy Analyzer};
      C --> E(OS ID Inference Engine);
      D --> F(Malware Behavior Inference Engine);
      E --> G(ASIC Alert Generator);
      F --> G;
      G --> H[High-Speed Alert Output];
  

2. Operational Parameter Expansion

Derivative 2.1: Nanoscale Network Monitor for On-Chip Security

• Enabling Description: A defensive disclosure for an integrated circuit (IC) with embedded nanoscale network monitoring capabilities. This system operates at the chip level, analyzing inter-core or inter-component communication packets for OS fingerprinting and malware detection. The "access device" in this context is the Network-on-Chip (NoC) interconnect, and the "computing device" refers to individual CPU cores, specialized accelerators, or embedded microcontrollers on the same die. The monitoring logic, implemented using sub-micron transistors, observes packet headers (e.g., internal TCP/IP stack representations within a virtualized environment on-chip) and metadata of data flows between components. OS ID determination involves fingerprinting the virtualized OS instances running on specific cores (e.g., differences in context-switching overhead visible in timing, specific memory access patterns that reveal OS type). Malware detection uses ultra-compact, hardware-decoded signatures for known on-chip malware (e.g., side-channel attacks, data leakage patterns) and real-time anomaly detection by monitoring bus arbitration, cache utilization, and instruction patterns against baselines. Alerts, including the originating core ID (network address equivalent), malware ID, and detected OS, are generated as high-priority interrupts to a secure enclave on the chip.
• Mermaid Diagram:

  graph LR
      A[On-Chip Network (NoC)] --> B(Nanoscale Packet Tap);
      B --> C{OS Fingerprint Logic};
      B --> D{Malware Pattern Detector};
      C -- Core OS Type --> E(Correlation & Alert Logic);
      D -- On-Chip Malware ID --> E;
      E --> F[Secure Enclave Interrupt];
  

Derivative 2.2: Industrial-Scale Telco Network Malware Detection

• Enabling Description: A security monitoring solution designed for Carrier-Grade Ethernet (CGE) and 5G core networks, handling exabytes of data traffic per day. The system comprises distributed network sensors operating at 400Gbps+ line rates, deployed at various points within the telco infrastructure (e.g., peering points, aggregation routers, 5G user plane function UPs). Each sensor utilizes specialized deep packet inspection (DPI) hardware offload engines. OS identification is performed by a combination of high-speed TCP/IP stack fingerprinting, HTTP/2 and QUIC header analysis (for User-Agent equivalent information), and heuristic analysis of traffic patterns (e.g., device types, cellular IoT module fingerprints). Malware detection leverages continuously updated global threat intelligence feeds for signature comparison, augmented with real-time machine learning models for detecting zero-day exploits and polymorphic malware. The system correlates alerts not just to an access device's IP (e.g., a residential gateway), but also to a subscriber ID, location, and the specific computing device identified by its OS within that subscriber's network, even through multiple layers of NAT/CGNAT. Alerts are aggregated, deduplicated, and prioritized by a central Big Data analytics platform before being dispatched to network operations centers (NOCs) and security operations centers (SOCs) with geo-location and subscriber-specific OS details.
• Mermaid Diagram:

  graph TD
      A[400Gbps+ Network Traffic] --> B(Distributed DPI Sensors);
      B --> C{High-Speed OS Fingerprinting};
      B --> D{Real-time Malware Detection};
      C -- OS ID, Subscriber Data --> E(Big Data Analytics Platform);
      D -- Malware ID --> E;
      E --> F[Aggregated & Prioritized Alerts];
      F --> G{NOC/SOC};
  

Derivative 2.3: Ultra-Low Latency Malware Detection for Financial Trading Networks

• Enabling Description: A network security system engineered for extreme low-latency environments such as high-frequency trading (HFT) networks, where detection and alerting must occur within microseconds. The system employs in-line network taps and FPGA-based processing units co-located with trading engines, allowing for wire-speed packet capture and analysis with determinism. OS identification relies on highly optimized TCP/IP stack fingerprinting performed by dedicated FPGA logic, analyzing the initial SYN packet with nanosecond precision. The "computing devices" are specialized trading servers, and the OS types are typically hardened Linux distributions or custom real-time operating systems. Malware detection involves a minimal set of pre-compiled, hardware-accelerated signatures targeting specific trading-related malware (e.g., latency manipulation, data exfiltration, market spoofing). Critical indicators are processed immediately. Any detected malware or suspicious OS anomaly generates a low-latency alert directly to a dedicated risk management system, including the network address of the affected trading server, the malware/anomaly ID, and the OS ID, enabling immediate mitigation (e.g., circuit breaking the trading connection). The entire detection pipeline is optimized to introduce minimal jitter and latency.
• Mermaid Diagram:

  sequenceDiagram
      participant NT as Network Traffic
      participant FP as FPGA Processor
      participant RMS as Risk Management System
  
      NT ->> FP: Packet (e.g., SYN)
      activate FP
      FP ->> FP: Detect OS ID (nanoseconds)
      FP ->> FP: Compare Malware Signatures
      alt Malware/OS Anomaly Detected
          FP ->> RMS: Ultra-Low Latency Alert (Server IP, Malware ID, OS ID)
      else No Detection
          FP -->> NT: Forward Packet (minimal delay)
      end
      deactivate FP
  

3. Cross-Domain Application

Derivative 3.1: ICS/SCADA Network Anomaly & OS Identification

• Enabling Description: A specialized security monitoring solution deployed within Industrial Control Systems (ICS) and SCADA environments, aimed at protecting critical infrastructure. Network sensors are integrated into industrial Ethernet switches or deployed passively on mirrored ports, monitoring Modbus/TCP, EtherNet/IP, OPC UA, and other industrial protocols. OS identification is crucial for inventorying and securing diverse operational technology (OT) devices, ranging from Windows Embedded HMIs to proprietary RTOS PLCs and Linux-based industrial gateways. The system employs specialized fingerprinting for these industrial OS variants by analyzing unique protocol stack implementations, response timing, and vendor-specific protocol extensions. Malware detection focuses on behavioral anomalies characteristic of ICS attacks (e.g., unauthorized PLC programming commands, changes in sensor data patterns, unusual data exfiltration over industrial protocols, reconnaissance activities against specific RTOS devices). Alerts include the IP address of the compromised industrial controller, the identified OT OS (e.g., "Siemens S7 RTOS," "Windows Embedded Standard 7"), and the detected anomaly/malware type, facilitating immediate isolation and forensic analysis of critical systems.
• Mermaid Diagram:

  graph TD
      A[ICS/SCADA Network Traffic] --> B(Industrial Network Sensor);
      B --> C{OT Protocol Parser};
      C --> D{Industrial OS Fingerprinter (RTOS, Embedded)};
      C --> E{ICS Malware/Anomaly Detector};
      D -- OT OS ID --> F(ICS Alert Manager);
      E -- ICS Malware ID --> F;
      F --> G[SCADA/DCS Integration (for action)];
  

Derivative 3.2: Healthcare IoT Device Security Monitoring

• Enabling Description: A security system tailored for healthcare networks, specifically monitoring connected medical devices and Internet of Medical Things (IoMT). Sensors are deployed at hospital network segments, monitoring DICOM, HL7, MQTT, and proprietary medical device communication protocols. OS identification is critical for maintaining an accurate inventory of vulnerable medical devices (e.g., infusion pumps running embedded Linux, MRI machines on Windows XP, patient monitors with custom firmware). The system fingerprints these devices by analyzing unique network stack implementations, device-specific beacon protocols, and manufacturer-defined protocol deviations. Malware detection targets known vulnerabilities in medical device firmware, exploitation attempts against legacy OS, and abnormal data access patterns (e.g., unauthorized PHI access, ransomware activity impacting imaging systems). Alerts are generated with the IP address of the affected medical device, its identified OS (e.g., "GE MRI Linux," "Baxter Infusion Pump OS"), and the specific malware/threat ID, enabling clinical engineering and IT security teams to isolate and remediate devices without disrupting patient care.
• Mermaid Diagram:

  flowchart TD
      A[Hospital Network Traffic] --> B(IoMT Security Sensor);
      B --> C{Medical Protocol Analyzer};
      C --> D{Medical Device OS Fingerprinter};
      C --> E{IoMT Malware & Anomaly Detector};
      D -- Device OS ID --> F(Healthcare Security Portal);
      E -- Threat ID --> F;
      F --> G[Clinical Engineering / IT Security Alerts];
  

Derivative 3.3: Automotive In-Vehicle Network (IVN) Malware Detection

• Enabling Description: A security monitoring system for connected vehicles, specifically analyzing internal automotive networks (e.g., CAN Bus over IP, Automotive Ethernet) for malware affecting infotainment, telematics, and autonomous driving ECUs. The "access device" is often the vehicle's gateway ECU, and "computing devices" are various Electronic Control Units (ECUs) running different OS (e.g., QNX, Android Automotive, AUTOSAR OS, custom RTOS). The system utilizes compact embedded sensors within the gateway ECU or central compute cluster. OS identification involves fingerprinting the specific RTOS or general-purpose OS running on each ECU by analyzing their unique network stack behaviors (e.g., specific TCP/IP option usage for connected services), diagnostic protocol responses, and software update mechanisms. Malware detection focuses on identifying unauthorized firmware updates, command injection attempts (e.g., manipulating sensor data, controlling vehicle functions), and data exfiltration from vehicle systems. Alerts, including the originating ECU ID (network address equivalent), the identified OS (e.g., "QNX Infotainment OS," "AUTOSAR Gateway OS"), and the detected malware/intrusion type, are sent to the vehicle's secure cloud backend for forensic analysis and over-the-air (OTA) remediation planning.
• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Ingress
      Ingress --> Parse_IVN_Packets : Automotive Ethernet/CAN_over_IP
      Parse_IVN_Packets --> Fingerprint_ECU_OS : Analyze TCP/IP, Diag Protocols
      Fingerprint_ECU_OS --> Detect_IVN_Malware : Compare to Automotive Threat DB
      Detect_IVN_Malware --> Generate_Alert : ECU ID, OS ID, Malware Type
      Generate_Alert --> Cloud_Backend : Encrypted Alert Transmission
      Cloud_Backend --> [*]
  

4. Integration with Emerging Tech

Derivative 4.1: AI-Driven Adaptive OS Fingerprinting & Anomaly Malware Detection

• Enabling Description: A network security system that leverages deep learning models for adaptive OS fingerprinting and unsupervised anomaly detection for malware. Network sensors capture raw TCP/IP packets. An initial OS ID is determined via conventional SYN/User-Agent analysis. This data, along with packet length distributions, inter-arrival times, TLS handshake patterns (e.g., cipher suites, extensions), and HTTP headers, feeds into a recurrent neural network (RNN) or transformer model for OS classification. The AI continuously refines OS identification based on evolving network stack characteristics and new device types, achieving high accuracy even for custom or obscured OS. For malware, an autoencoder or Generative Adversarial Network (GAN) learns a baseline of "normal" network traffic behavior for each identified OS type. Deviations from this baseline, such as unusual port activity, non-standard protocol usage, or C2-like traffic patterns, trigger anomaly alerts. The alert includes the network address, a probability score for specific malware families or types of anomalies, and the AI-refined OS ID. A feedback loop from confirmed remediations improves model accuracy.
• Mermaid Diagram:

  graph LR
      A[Raw TCP/IP Packets] --> B(Network Sensor);
      B --> C{Feature Extractor};
      C --> D[AI-Powered OS Classifier];
      C --> E[AI-Powered Anomaly Detector];
      D -- Refined OS ID --> F(Alert & Feedback Loop);
      E -- Anomaly/Malware ID --> F;
      F --> G[Alert Manager];
      G --> H[Threat Intelligence Feed];
      F --> I[Model Retraining];
      I --> D;
      I --> E;
  

Derivative 4.2: IoT Sensor-Enriched Malware Context & Remediation Orchestration

• Enabling Description: A network-based security system where malware detection is augmented by real-time data from endpoint Internet of Things (IoT) sensors. Network sensors detect malware and OS IDs as per the original patent. Simultaneously, IoT agents or embedded firmware on managed IoT devices (e.g., smart cameras, industrial sensors, smart home devices) transmit telemetry (e.g., CPU load, memory usage, network interface statistics, temperature, power consumption, process lists) to a centralized IoT context platform. When a network sensor generates a malware alert for an access device, the system correlates this with IoT sensor data for devices behind that access device. If an IoT device's OS (fingerprinted on the network) matches the alert's OS ID, and its telemetry indicates suspicious activity (e.g., sudden CPU spikes, unusual outbound connections), the alert's confidence level is elevated, and a detailed remediation orchestration plan is initiated. This plan might involve dynamically updating IoT device firewall rules via a cloud-based management platform, quarantining the device on a segmented VLAN, or triggering a firmware integrity check.
• Mermaid Diagram:

  sequenceDiagram
      participant NS as Network Sensor
      participant IoT_D as IoT Device
      participant IoT_CP as IoT Context Platform
      participant AM as Alert Manager
      participant RO as Remediation Orchestrator
  
      NS ->> AM: Malware Alert (Access Device IP, Malware ID, OS ID)
      IoT_D ->> IoT_CP: Telemetry Data (Device ID, OS, Metrics)
      AM ->> IoT_CP: Query for matching IoT devices
      IoT_CP ->> AM: Correlated IoT Device Data (if match)
      AM ->> RO: Enriched Malware Alert & Remediation Request
      RO ->> IoT_D: Trigger Remediation (e.g., Quarantine, FW Update)
  

Derivative 4.3: Blockchain-Verified Malware Signature & OS Fingerprint Trust

• Enabling Description: A network security system that incorporates blockchain technology to ensure the integrity and provenance of malware signatures and OS fingerprint databases. Network sensors determine OS ID and malware presence. However, the malware signature database and OS fingerprint database are distributed and verified on a private blockchain (e.g., Hyperledger Fabric or enterprise Ethereum). Each new malware signature or OS fingerprint update is cryptographically signed by an authorized threat intelligence provider and recorded as a transaction on the blockchain. Network sensors, before performing malware detection or OS identification, query the blockchain to verify the integrity and timestamp of their local signature/fingerprint database copies. This prevents malicious tampering of detection rules. Alerts generated by the system include not only the network address, malware ID, and OS ID, but also a blockchain transaction ID (TxID) that proves the validity of the detection rules used. Remediation portal access could also leverage blockchain for user identity verification and tracking remediation status.
• Mermaid Diagram:

  graph TD
      A[Threat Intelligence Providers] --> B(Blockchain Network);
      B --> C{Malware Signatures / OS Fingerprints};
      C -- TxID, Timestamp, Signature --> D[Network Sensor (Local DB)];
      D --> E{Verify DB Integrity (via Blockchain Query)};
      E --> F{OS ID Determination};
      E --> G{Malware Detection};
      F -- Validated OS ID --> H(Alert Generator);
      G -- Validated Malware ID --> H;
      H -- Includes TxID --> I[Alert Manager];
  

5. The "Inverse" or Failure Mode

Derivative 5.1: Fail-Safe Isolation Mode for Undetermined OS/Malware

• Enabling Description: A network-based security monitoring solution where, in cases of critical system failure or an inability to definitively determine either the OS ID of a computing device or the presence of malware (e.g., due to highly evasive techniques, sensor overload, or corrupted signatures), the system defaults to a fail-safe isolation mode. If an OS ID cannot be determined after multiple attempts using SYN fingerprinting and HTTP User-Agent analysis, or if a high-confidence malware determination is impossible (e.g., polymorphic malware with no signature match, zero-day threat), the network sensor initiates an automated isolation procedure. This involves sending a command to an inline network access control (NAC) device or a managed switch to automatically place the offending access device's port or the entire subnet into a quarantine VLAN, severely limiting its network connectivity (e.g., only allowing access to a captive portal for security updates or remediation). The generated alert explicitly states "OS/Malware Undetermined - Fail-Safe Isolation Engaged," along with the access device's network address.
• Mermaid Diagram:

  flowchart TD
      A[Receive TCP Packets] --> B{Determine OS ID?};
      B -- No / Unreliable --> C{Critical Malware Detect?};
      B -- Yes --> D{Critical Malware Detect?};
      C -- No / Undetermined --> E[Initiate Fail-Safe Isolation];
      C -- Yes --> F[Generate Alert (Malware ID, OS ID)];
      D -- No / Undetermined --> E;
      D -- Yes --> F;
      E --> G[Alert: "Undetermined - Isolated"];
      F --> H[Alert: "Malware Detected"];
      E --> I[Quarantine Network Segment];
  

Derivative 5.2: Low-Power/Limited-Functionality Mode for Edge Devices

• Enabling Description: A network security system designed for deployment on resource-constrained edge devices (e.g., low-power IoT gateways, consumer routers) with limited computational power and energy budgets. In its default low-power mode, the network sensor performs a simplified OS fingerprinting process, primarily relying on analyzing only the initial TCP SYN packet headers for a coarse-grained OS ID (e.g., "Windows-like," "Linux-like," "Mobile OS") and skipping deeper User-Agent analysis or full TLS fingerprinting. Malware detection is limited to a minimal set of high-priority, energy-efficient signatures targeting widespread threats (e.g., basic botnet C2 traffic, common ransomware patterns) and performs only statistical anomaly detection on flow metadata (e.g., total bytes, connection count per hour) rather than deep payload inspection. Alerts are aggregated and batched for transmission at scheduled intervals to minimize radio usage. The alert contains the access device's network address, the "limited-detection" malware ID (if any), and the coarse-grained OS ID. A full-scan mode can be activated on demand for more thorough analysis.
• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Low_Power_Mode
      Low_Power_Mode --> Simplified_OS_Fingerprint : Analyze SYN Only
      Simplified_OS_Fingerprint --> Limited_Malware_Detect : High-Priority Signatures / Flow Stats
      Limited_Malware_Detect --> Aggregate_Alerts : Batch Alerts
      Aggregate_Alerts --> Transmit_Alerts_Periodically : Energy-Efficient Tx
      Transmit_Alerts_Periodically --> Low_Power_Mode
      Low_Power_Mode --> Full_Scan_Mode : On-Demand Activation
      Full_Scan_Mode --> Detailed_OS_Fingerprint : SYN + UA + TLS
      Detailed_OS_Fingerprint --> Full_Malware_Detect : DPI + ML
      Full_Malware_Detect --> Immediate_Alert_Tx : Real-time Tx
      Immediate_Alert_Tx --> Full_Scan_Mode
      Full_Scan_Mode --> Low_Power_Mode : Return to Low-Power
  

Derivative 5.3: Privacy-Preserving Malware Detection with Anonymized OS IDs

• Enabling Description: A network-based malware detection system designed to operate in environments with strict data privacy regulations (e.g., GDPR, CCPA). The system performs OS identification and malware detection, but all generated alerts and associated data are anonymized or pseudonymized prior to storage or transmission. When determining the OS ID, specific identifying characteristics (e.g., exact OS version, patch level) are generalized to broad categories (e.g., "Windows Desktop," "Linux Server," "iOS Mobile"). Network addresses of access devices are hashed or obfuscated, and subscriber IDs are pseudonymized using a one-way cryptographic function, preventing direct linkage to individuals. Malware IDs are maintained for threat intelligence, but detailed payload information that could contain personally identifiable information (PII) is discarded or processed in a secure enclave that ensures privacy preservation. Alerts sent to external entities (e.g., a service provider's security operations center) contain only the pseudonymized access device ID, the generalized OS ID, and the malware ID, ensuring that remediation efforts can proceed without compromising individual user privacy.
• Mermaid Diagram:

  graph LR
      A[Raw TCP Packets] --> B(Network Sensor);
      B --> C{OS Fingerprint (Detail)};
      B --> D{Malware Detect (Payload)};
      C --> E[Anonymize OS ID (Generalize)];
      D --> F[Anonymize PII from Malware Context];
      E --> G(Privacy-Preserving Alert Composer);
      F --> G;
      G --> H[Pseudonymize Access Device ID];
      H --> I[Anonymized Alert Output];
  

Combination Prior Art Scenarios

Here are three scenarios combining US patent 8635697 with existing open-source standards to create obvious prior art.

1. US8635697 + Zeek (formerly Bro)

• Combination: A system and method where a network sensor (as described in US8635697) is implemented using the open-source Zeek Network Security Monitor. Zeek's powerful scripting language and event-driven architecture are used to perform the OS identification and malware detection steps.
• Enabling Description: A network sensor deploys Zeek, configured to run custom scripts. The Zeek scripts would:
  • Receive TCP packets: Zeek inherently processes raw network traffic, including TCP sessions.
  • Determine OS ID: Utilize Zeek's built-in conn record fields (e.g., id.orig_h, id.resp_h) and conn_state for session tracking. OS fingerprinting would be implemented using Zeek's packet_filter functionality to inspect initial SYN packets (for TCP options, window sizes, TTL, etc., as per US8635697's description of OS fingerprinting via TCP/IP stack analysis) and http_info events to extract User-Agent strings. A custom Zeek script would then map these fingerprints to a known OS database (e.g., similar to nmap-os-db).
  • Determine Malware Presence: Leverage Zeek's file_analysis framework for content inspection against malware signatures (e.g., by integrating with external YARA rules or specialized pattern matching logic in a custom Zeek plugin). Zeek's protocol analyzers (e.g., HTTP, DNS) would also be used to detect known malware C2 patterns or suspicious behaviors.
  • Generate Alert: Upon detection of malware and associated OS ID, a Zeek script would generate a notice event. This event would be formatted to include the id.orig_h (network address of the access device), a derived malware ID (e.g., signature name or anomaly type), and the identified OS ID, which can then be logged to a central SIEM or alert manager.

2. US8635697 + Snort/Suricata

• Combination: A network-based malware detection system where the core malware signature comparison and preliminary OS identification are performed by an open-source Intrusion Detection System (IDS) like Snort or Suricata, integrated with a custom module for refined OS ID and alert generation as per US8635697.
• Enabling Description: A network sensor runs Snort/Suricata in inline or passive mode.
  • Receive TCP packets: Snort/Suricata processes all network traffic, including TCP sessions.
  • Determine OS ID: Snort/Suricata rules can be written to detect OS fingerprints. For example, specific ip.ttl and tcp.window values in SYN packets can hint at an OS. User-Agent strings in HTTP traffic can also be matched using Snort/Suricata's content matching rules. While not full-fledged OS fingerprinting like Nmap, these rules provide a "first OS ID" (as per claim 2 of US8635697). A custom preprocessor or Lua script (in Suricata) could extract these details more robustly and correlate them.
  • Determine Malware Presence: This is the primary function of Snort/Suricata, using its extensive rule sets (sid) to compare network packets against known malware signatures and behavioral patterns.
  • Generate Alert: When a Snort/Suricata rule fires (detecting malware) that also has associated OS fingerprinting rules, the alert (e.g., snort.alert or eve.json in Suricata) would be enriched. A custom output plugin or a post-processing script would collect the originating network address, the sid (malware ID), and the identified OS ID from the rule or associated flow data, then generate the comprehensive alert as described in US8635697.

3. US8635697 + Open vSwitch (OVS)

• Combination: A virtualized network security solution where the network sensor for OS identification and malware detection (as per US8635697) is implemented as a virtualized network function (VNF) integrated directly into the packet forwarding path of Open vSwitch (OVS) within a cloud or data center environment.
• Enabling Description: In a virtualized environment, OVS acts as the access device, forwarding traffic between virtual machines (computing devices) and external networks.
  • Receive TCP packets: An OVS instance is configured with OpenFlow rules to mirror or redirect specific TCP traffic flows to a dedicated VNF acting as the network sensor.
  • Determine OS ID: The VNF (e.g., a Linux container running a packet analysis engine like p0f or custom Python scripts using Scapy for TCP/IP stack fingerprinting, and parsing HTTP User-Agent headers) would receive the mirrored/redirected traffic. It determines the OS ID of the source VM (computing device) by analyzing SYN packets and HTTP headers.
  • Determine Malware Presence: The same VNF would include a malware detection engine (e.g., integrating a lightweight ClamAV daemon for file transfers, or rules-based inspection for C2 traffic patterns) to compare packet contents against malware signatures.
  • Generate Alert: Upon detection, the VNF generates an alert that includes the VM's internal IP address (which OVS can map to its external facing interface, representing the "network address associated with the access device"), the malware ID, and the identified OS ID. This alert is sent to a central cloud security manager, which can then dynamically update OVS flows to quarantine the infected VM or redirect its traffic for further inspection.