US 7185368

I'll verify the patent details and check for any 2026 litigation activity.

Let me pull the actual claim text to summarize the independent claims accurately.

Let me try to confirm the exact wording of the earlier independent claims.

US Patent 7,185,368 — Verification Summary

Important caveat first: I could not access the USPTO PatentCenter/PAIR record or a CAFC docket directly in this session (no live USPTO or CAFC database query tool was available to me — only general web search). What follows is grounded in the authoritative full patent text provided to me plus corroborating public sources (Google Patents, Justia, the printed patent PDF). I flag below where I am certain vs. uncertain. I found no CAFC 2026 docket or pending Federal Circuit appeal specifically naming 7,185,368.

Bibliographic data (high confidence)

Minor source discrepancies to note (not auto-corrected):

• One aggregator (Unified Patents portal) lists a priority date of 2000-11-29 for US-7185368-B2, whereas Google Patents and the printed patent state Nov. 30, 2000. The patent document itself controls: Nov. 30, 2000.
• Google Patents lists "Lancope LLC" as original assignee in its structured data; the printed patent face lists "Lancope, Inc., Atlanta, GA." These are the same entity at different times (a 2016 change-of-name record converts Lancope, Inc. → Lancope LLC).

Abstract (as issued)

"A flow-based intrusion detection system for detecting intrusions in computer communication networks. Data packets representing communications between hosts in a computer-to-computer communication network are processed and assigned to various client/server flows. Statistics are collected for each flow. Then, the flow statistics are analyzed to determine if the flow appears to be legitimate traffic or possible suspicious activity. A concern index value is assigned to each flow that appears suspicious. By assigning a value to each flow that appears suspicious and adding that value to the total concern index of the responsible host, it is possible to identify hosts that are engaged in intrusion activity. When the concern index value of a host exceeds a preset alarm value, an alert is issued and appropriate action can be taken."

Plain-language overview

The patent claims a way to detect network attacks without string-matching packet payloads against attack "signatures" (and without pure statistical baselining). Instead:

1. A monitoring appliance passively reads packet headers (only headers — no deep payload inspection), in promiscuous mode.
2. Packets between two hosts using the same service (one port held constant) are grouped into a client/server (C/S) flow; the lower IP address is designated ip[0], the higher ip[1]. A flow ends after inactivity (330 s in the embodiment), or on a FIN/RESET event.
3. Per-flow statistics (packet counts, byte counts, start/last times, TCP-flag bitmaps) are accumulated in a flow data structure.
4. A "logic-tree" analysis classifies each finished flow as normal or suspicious (e.g., TCP probe = many packets answered by many resets; UDP probe = UDP answered by ICMP "port unavailable"; half-open attack; stealth port scans; bad/undefined TCP flag combinations; "short" UDP with no data; address/port scans).
5. A suspicious flow is assigned a "concern index" (CI) — a predetermined, heuristically fixed point value from lookup tables (Table I for flows, Table II for other events).
6. CI values are accumulated per host in a host data structure.
7. When a host's cumulative CI crosses a preset alarm threshold, the alert manager thread raises an alarm and can notify an operator, send SNMP traps/e-mail, or drive a firewall to block the offending host.

Architecturally the engine has three threads: a packet classifier, a flow collector (periodic sweep), and an alert manager, reading/writing a shared database of flow and host records.

Independent claims (plain language)

(Verified from the Justia claim listing and the patent's own description; the patent has 37 claims total.)

Claim 30 — Method of analyzing traffic (core flow/CI/host method). Monitor packet headers exchanged between two hosts, each with an IP address; determine the existence of a C/S flow as a predetermined plurality of packets exchanged between a particular port of one host that remains constant; collect C/S flow data from packet headers; assign a concern index value to a determined C/S flow based on that data; maintain a host data structure accumulating concern index values across multiple flows for the same host; and issue an alarm when the host's accumulated concern index exceeds an alarm threshold.

Claim 33 — System for analyzing traffic. A computer system operative to: (a) monitor packet headers; (b) classify packets into C/S flows, where a C/S flow corresponds to packets exchanged between two hosts associated with a single service; (c) analyze the C/S flows to assign a concern index value to a potentially suspicious flow, where each concern index value for a given activity is a predetermined fixed value; (d) generate an alarm signal in response to cumulated concern index values — plus a communication system to receive the packets.

Claim 35 — System (file/memory structure variant). A processor operative to: (a) monitor packet headers; (b) classify into C/S flows per single service; (c) maintain a flow data structure; (d) assign a predetermined, fixed concern index value to a suspicious flow; (e) cumulate concern index values for a particular host; (f) maintain a host data structure associating a cumulated CI value with each host; and (g) generate an alarm signal based on cumulated CI values — with a memory storing the two data structures and a network interface to receive packets.

Claim 37 — Method for short-UDP detection. Monitor packets between two hosts; identify packets from one host whose transport-layer protocol specifies a packet format having a data segment; if the protocol is UDP and the data segment contains two bytes or less, store a predetermined concern index value in memory in association with the host that issued the UDP packet; and issue an alarm when that host's cumulated concern index exceeds a threshold.

(Note: dependent claims 31–32, 34, 36, and 38+ further narrow these, e.g., reciting the C/S-flow delimiters — inactivity time, FIN flag, port traffic characteristics, RESET — and the enumerated suspicious categories: potential TCP probe, potential UDP probe, half-open attack, TCP/UDP stealth port scan, bad flags, short UDP, address scan, port scan.)

⚠️ Uncertainty — earlier independent claims (1 / 6 / 25)

The full claim text supplied to me was truncated before the claims section, and my searches returned only the later claims (26–37). I can confirm that claim 6 is a method claim about C/S flows (claim 27 depends from it) and that claim 25 ends with "in response to the alarm signal, sending a message to a utilization component," with claims 26 and 29 depending from claim 25. I cannot state with confidence the exact wording of claims 1, 6, or 25, nor definitively list every independent claim. Based on the structure (37 claims, claim 9 in the foreign counterpart corresponding to a system claim), the independent set most likely includes a set of method and system claims numbered roughly 1, 6, 25(?), 30, 33, 35, and 37 — but this is inference, not authoritative. For a definitive independent-claim list, the issued patent's claim 1 text or USPTO/PatentCenter's full-text claims should be consulted directly.

Litigation / PTAB relevance (verified via secondary sources)

• The patent appears extensively as prior art and in claim charts in the Cisco Systems v. Centripetal Networks inter partes reviews (e.g., IPR2018-01654 and IPR2018-01655, both filed Sept. 17, 2018) — Exhibit 1006 in each is the Copeland US 7,185,368 patent.
• It is also cited in IPR2023-00554 (Cisco Systems v. Orckit Corporation) claim charts.
• These are PTAB proceedings invoking 7,185,368 as prior art; I found no record of 7,185,368 itself being the subject of a 2026 CAFC appeal. Absence of a hit in my searches is not proof of absence — a targeted PACER/CAFC docket query would be required to confirm.

Bottom line: US 7,185,368 is the foundational Lancope/Copeland flow-based intrusion-detection patent (assigned today to Cisco Technology, Inc.), filed Nov. 30, 2001, issued Feb. 27, 2007, and expired May 5, 2024 after an 887-day term adjustment. Its core inventive concept — header-only flow statistics feeding a per-flow "concern index" accumulated per host against an alarm threshold — is captured in independent claims 30, 33, 35 (and 37 for short-UDP), with the exact scope of claims 1, 6, and 25 unconfirmed in this session.

I'll research litigation involving US 7,185,368 across patent litigation trackers and court sources.

I need to be careful — several results reference US 7,738,368, a different patent. Let me search more specifically for the exact number 7,185,368.

Let me dig deeper into litigation databases and check whether 7,185,368 was ever asserted (as opposed to cited as prior art).

Litigation search: US Patent 7,185,368

Bottom line: Based on my searches, I found no district-court litigation (or ITC investigation) in which US 7,185,368 was the asserted patent-in-suit. Every appearance of this specific number that I could locate is as prior art / a cited reference inside other parties' proceedings, not as an asserted patent. I flag my search limitations below, because absence of a hit is not proof of absence.

Critical caution — don't conflate similar numbers

My searches repeatedly surfaced a different patent, US 7,738,368 (the "368 Patent"), which IS heavily litigated — e.g., Croga Innovations Ltd. v. Cisco Systems, Inc., No. 2:24-cv-00065-JRG (E.D. Tex.), and IPR2024-01282. Per your instruction to interpret IDs literally and not return results for similar numbers, I have excluded that matter: 7,738,368 ≠ 7,185,368. If a source mixed them, treat it as erroneous.

What I did find for 7,185,368 (as a cited reference, not an asserted patent)

Litigation where Lancope/Copeland-heritage products were involved (context, not this patent)

The prior-generated section noted Cisco's acquisition of Lancope (2016) and the Centripetal v. Cisco, No. 2:18-cv-00094-HCM-LRL (E.D. Va. Norfolk Div.) action. But in that case the asserted patents were Centripetal's (e.g., 9,686,193; 9,560,176; 9,413,722; 9,203,806; 9,160,713; 9,124,552; 9,565,213; 9,674,148; 9,917,856), with 7,185,368 appearing only as Cisco's prior art, not as a claim in suit.

⚠️ Search limitations / confidence

• I could not directly query the Unified Patents litigation caselist (portal.unifiedpatents.com/litigation/caselist), PACER, USPTO PTAB/PatentCenter, or the CAFC docket in this session — my searches hit a step limit and returned only general web/aggregator results. A definitive "no litigation" conclusion requires a targeted PACER and Unified Patents caselist query.
• Accordingly, I state with high confidence that 7,185,368 appears as prior art in the PTAB proceedings above, and with moderate confidence (not certainty) that it has never been asserted in a district-court/ITC case. I found no complaint, case number, jurisdiction, filing date, or outcome for 7,185,368 as a patent-in-suit — because I found no such case.

Summary table (as requested)

Recommendation to confirm: run a direct PACER docket search and the Unified Patents litigation caselist filtered to 7185368 (and separately confirm none of the hits are the look-alike 7738368). If you can supply access to those databases or a specific docket number, I can pin down parties, jurisdiction, case numbers, filing dates, and disposition definitively.

I'll verify the structured "no proceedings" signal against live sources, since well-asserted patents often attract trials that lag the ODP ingest.

Let me probe specifically for any proceeding where 7,185,368 itself was the challenged patent, and check aggregator/portal records.

Let me run a few more targeted checks — including CBM/PGR and any proceeding naming 7,185,368 as the patent under review.

PTAB Proceeding Analysis — US 7,185,368 ("Flow-based detection of network intrusions")

Proceedings overview

Zero AIA trial proceedings have ever been filed against US 7,185,368. The USPTO Open Data Portal structured record ("no AIA trial proceedings on file as of the most recent ingest") is corroborated by my independent search: I found no IPR, PGR, or CBM in which Copeland's '368 patent is the patent under review — the only PTAB appearances of this number are as a prior-art exhibit (Ex. 1006), not a challenged patent (details below). Because the patent is expired (adjusted expiration 2024-05-05) and was never subjected to an AIA validity trial, there is no claim-level PTAB outcome to work from: all 37 claims stand untested before the Board, and a defendant today has no PTAB estoppel or cancellation to leverage — but also no real chance to file a fresh IPR of practical value, since the patent has lapsed. Defensive posture is therefore "expired and un-litigated at the PTAB," not "hardened by surviving IPRs."

I want to be explicit about the negative result rather than pad the template: the per-proceeding sections requested below would require proceeding numbers, judges, institution dates, and FWD dispositions that do not exist for this patent. I will not manufacture them. What follows instead is (a) the false-positive traps you must not mistake for proceedings on this patent, and (b) the genuine defensive picture.

⚠️ False positives — do NOT treat these as proceedings on 7,185,368

Two different, similarly-numbered patents generate "368" noise; a careless docket query will conflate them:

1. RE42,368 E (Fujitsu Network Communications v. Capella Photonics). IPR2014-01166, IPR2015-00726, IPR2015-01958. This is a reissue of U.S. 6,498,872 (an optical wavelength-switch patent) — completely unrelated to network intrusion detection. The string "RE42,368 E" is what matches "'368." Not your patent. (Institution decision, IPR2014-01166)

2. US 7,738,368 (Croga Innovations v. Cisco/Fortinet/Palo Alto; also Cisco Systems, Inc. v. Croga Innovations, IPR2024-01282). A different seven-million-series patent asserted in E.D. Tex. (Croga Innovations Ltd. v. Cisco, No. 2:24-cv-00065) and subject to a 2024 IPR. Same trailing three digits, unrelated disclosure. Not your patent. (IPR2024-01282 petition)

Where 7,185,368 actually shows up at the PTAB — as prior art, not as the target

• Cisco Systems, Inc. v. Centripetal Networks, Inc., IPR2018-01654 and IPR2018-01655 (filed 2018-09-17; challenged patent U.S. 9,560,176). In each, Ex. 1006 is US 7,185,368 (Copeland) — Cisco used the Lancope/Copeland patent (which Cisco by then owned, having acquired Lancope in 2016) as prior art against Centripetal. Both proceedings ended in Institution Denied (institution decision 2019-05-06). (PlainSite docket, IPR2018-01655)
• The '368 reference likewise appears in IPR2023-00554 (Cisco Systems v. Orckit) claim charts and in various Cisco/Palo Alto IPRs against Centripetal (e.g., IPR2021-01521) as cited art.
• A recent petition exhibit listing (PTAB petition 1558605) also cites "US-7185368 B2, 02-27-2007, Copeland III" on an IDS/citation form — again, cited-art usage.

None of these is an AIA trial of 7,185,368. Using a patent as prior art against someone else's patent does not create estoppel against claims of this patent, and produces no claim-level outcome for it.

Strategic summary

Claim status: everything is UNTESTED. No PTAB claim has ever been canceled, confirmed, or construed for US 7,185,368. There is no FWD, no certificate of cancellation, no substitute claim, and therefore no narrowed surviving claim set. If a demand letter or complaint asserts this patent, every claim (including the independent claims discussed in the earlier verification section — claims 30, 33, 35, and 37, with 1/6/25 unconfirmed) is a live infringement theory, and the usual "file an IPR and knock out claim 1" playbook has purely prophylactic value here rather than a ready-made kill shot.

Estoppel landscape: effectively empty. 35 U.S.C. § 315(e)(2) estoppel only attaches to a petitioner that obtains an FWD or that settles after institution. Since no petitioner ever reached institution on this patent, there is no estoppel bar on any prior-art ground — a defendant is free to raise, in district court or in a defensive posture, any § 102/§ 103/§ 112 theory (subject only to the normal district-court rules). The flip side is that no third party has already done the invalidity work for you: there is no public FWD claim construction or prior-art roadmap specific to this patent to borrow. The one strategic asset that does exist is the near two-decade record of 7,185,368 itself being cited as prior art by Cisco and others — its prosecution history (provisional priority to 2000-11-30, issued 2007-02-27, 887-day term adjustment) and the Copeland family (e.g., related US 7,512,980, US 7,475,426, US 10,129,273, plus the 2003/0105976 publication) are available as an art/specification resource.

Pattern signals. No repeat petitioner, no defensive aggregator (Unified Patents or similar) in the chain for this patent, and no patent-owner PTAB appeal — because there was never a proceeding to appeal. (Note: a Unified Patents portal page surfaced a row appearing to associate US-7185368-B2 with "Centripetal Networks LLC"; that is almost certainly adjacent-row bleed on an aggregator's related-patents table and contradicts the recorded chain Lancope, Inc. → Lancope LLC → Cisco Technology, Inc. (assignment 2016-06-15). Treat it as a data artifact, not an assignment.) The controlling ownership fact is that Cisco Technology, Inc. has held this patent since mid-2016 and it expired in 2024 — a configuration in which neither Cisco nor a third party has an incentive to open an IPR.

Recommended next steps

• If you are a defendant facing an assertion: do not expect a PTAB lifeline. There is no canceled claim to point to and no FWD to quote. Your invalidity case must be built de novo in district court (or in a fresh IPR if the patent were somehow still within its enforceable term — but it expired 2024-05-05, so for post-expiration conduct the practical defense is damages/royalty-basis and laches-type arguments, not claim cancellation). Verify the assertion is even directed at 7,185,368 and not the look-alikes 7,738,368 or RE42,368 before spending any budget.
• Confirm the negative directly. Because my sources are secondary (Google Patents, Docket Alarm, PlainSite, Justia) and no live USPTO API query tool was available in this session, run a final targeted check on PTAB E2E / Patent Trial & Appeal Board and USPTO PatentCenter for application 10/000,396 / patent 7,185,368, and on CourtListener for any Federal Circuit appeal naming the patent — absence of an appeal follows automatically from absence of an appealable FWD, but confirm it. I found no ex parte reexamination on file either; that too is worth a PatentCenter confirmation.
• Reuse the prior-art record. The most useful artifact this patent has generated is its own role as Ex. 1006 in Cisco v. Centripetal (IPR2018-01654/01655) and as a cited reference in the Cisco/Orckit and Centripetal-related IPRs. If you need to characterize the '368 disclosure or the Copeland family, those public filings are a vetted starting point — but remember they speak to other patents' validity, not to claim scope of 7,185,368.

Bottom line for a defendant: the honest answer is that there is no PTAB history on US 7,185,368 to exploit — the patent expired on 2024-05-05 having never been challenged in an AIA trial, so all claims remain formally intact but unenforceably aged, and no § 315(e)(2) estoppel exists in either direction. Any prior-art roadmap you use will be one you build yourself.

I'll research the assignment chain for this patent, then compile the analysis. Let me start with targeted searches.

Let me dig for the specific reel/frame records and the inventor's affiliation.

Assignment-chain analysis — US 7,185,368 B2

Sourcing note (read first): The assignment events below are taken from the authoritative full patent text supplied to me (the Google Patents "reassignment" legal-events block). I do not have live USPTO Assignment Center access in this session (only general web search), and my queries did not surface the reel/frame numbers or the correspondent of record for any of these recordings. Where the task asks for reel/frame or correspondent, I say so plainly rather than invent it. Execution dates are also not exposed by Google Patents — the dates shown are the recorded/assignment event dates; execution dates for the 2001 assignment are presumed to be on or about the Nov. 30, 2001 filing. Verify at the USPTO Assignment Center / Assignment Search by patent number 7185368.

Inventors

Notes / patterns:

• Single named inventor. There is no multi-inventor departure cluster to analyze — the "all inventors left within 12 months" tell is structurally inapplicable here.
• The patent face and the pre-grant publication (US 2003/0105976 A1) list the inventor as "John A. Copeland, III" — I interpret the suffix literally; note that some indices render the same person as "Copeland, John A." (Espacenet lists both "COPELAND III JOHN A" and "COPELAND JOHN A"). This is a name-variant discrepancy to flag, not a second inventor.
• ⚠️ I could not verify Copeland's precise employment relationship (Georgia Tech faculty vs. full-time Lancope) from primary records in this session; the Google Patents/Justia metadata does not state an employer. Treat the Georgia Tech affiliation as background corroboration, not a recorded fact.

Original assignee

• Lancope, Inc., Atlanta, GA (later of 3650 Brookside Parkway, Suite 400, Alpharetta, GA 30022, per the EPO/INPI counterpart EP1338130 record).
• Line of business: network behavior analytics and flow-based security. Its flagship product, StealthWatch, is exactly the commercial embodiment of this patent's claims (passive header/flow collection → "concern index"-style behavioral scoring → alarm).
• Shipped a product embodying the claims? Yes. StealthWatch was Lancope's core product (reportedly protecting 800+ enterprises/government networks by 2015).
• Current status: Acquired. Cisco announced the acquisition on Oct. 27, 2015 for $452.5M (cash + assumed equity + retention), and it was expected to close in Cisco's Q2 FY2016 (≈ Dec 2015–Jan 2016). Lancope's team joined Cisco's Security Business Group; the StealthWatch line became Cisco Secure Network Analytics. Lancope, Inc. ceased independent operation; it was first renamed Lancope LLC (2016-06-08 change-of-name record) and then merged into Cisco's ownership.

Assignment timeline

(Conveyance types and dates below are from the authoritative patent text's legal-events block. Reel/frame and correspondent fields were not retrievable in this session — flagged on each line.)

• 2001-11-30 (recorded 2001-11-30) — Reel not retrieved

  • Conveyance: Assignment of assignors' interest (original assignment)
  • Assignor: John A. Copeland, III
  • Assignee: Lancope, Inc.
  • Correspondent: ⚠️ not retrieved
  • Context: Formation of initial ownership — inventor assigns to the operating startup; standard founder assignment.

• 2005-10-24 — Reel not retrieved

  • Conveyance: Security Agreement
  • Assignor: Lancope, Inc.
  • Assignee: Venture Lending & Leasing IV, Inc., as Agent
  • Correspondent: ⚠️ not retrieved
  • Context: Venture-debt securitization — patent pledged as collateral for a loan, not a title transfer.

• 2008-04-18 — Reel not retrieved

  • Conveyance: Security Agreement
  • Assignor: Lancope, Inc.
  • Assignee: Silicon Valley Bank
  • Correspondent: ⚠️ not retrieved
  • Context: Securitization — collateral pledge to SVB.

• 2008-04-22 — Reel not retrieved

  • Conveyance: Security Agreement
  • Assignor: Lancope, Inc.
  • Assignee: Partners for Growth II, L.P.
  • Correspondent: ⚠️ not retrieved
  • Context: Securitization — second collateral pledge (growth lender).

• 2009-02-10 — Reel not retrieved

  • Conveyance: Release by Secured Party
  • Assignor: Venture Lending & Leasing IV, Inc.
  • Assignee: Lancope, Inc.
  • Correspondent: ⚠️ not retrieved
  • Context: Release of the 2005 lenders' security interest (loan satisfied/refinanced).

• 2009-11-23 — Reel not retrieved

  • Conveyance: Security Agreement
  • Assignor: Lancope, Inc.
  • Assignee: Silicon Valley Bank
  • Correspondent: ⚠️ not retrieved
  • Context: Securitization — renewed/continued SVB collateral pledge.

• 2014-05-28 — Reel not retrieved

  • Conveyance: Security Interest
  • Assignor: Lancope, Inc.
  • Assignee: Silicon Valley Bank
  • Correspondent: ⚠️ not retrieved
  • Context: Securitization — updated SVB security interest.

• 2014-06-02 — Reel not retrieved

  • Conveyance: Merger
  • Assignor: Lancope, Inc.
  • Assignee: Lancope, Inc.
  • Correspondent: ⚠️ not retrieved
  • Context: Internal corporate reorg — same-name merger (surviving entity "Lancope, Inc."); no change in ownership.

• 2015-11-24 — Reel not retrieved

  • Conveyance: Release by Secured Party
  • Assignor: Partners for Growth II, L.P.
  • Assignee: Lancope, Inc.
  • Correspondent: ⚠️ not retrieved
  • Context: Release of the 2008 growth lender's security interest (consistent with the Cisco sale clearing encumbrances).

• 2016-01-15 — Reel not retrieved

  • Conveyance: Termination and Release of Security Interests
  • Assignor: Silicon Valley Bank
  • Assignee: Lancope, Inc.
  • Correspondent: ⚠️ not retrieved
  • Context: Final release of SVB liens — patent unencumbered ahead of/at the Cisco close.

• 2016-06-08 — Reel not retrieved

  • Conveyance: Change of Name
  • Assignor: Lancope, Inc.
  • Assignee: Lancope LLC
  • Correspondent: ⚠️ not retrieved
  • Context: Name change only — same entity, no ownership change; convenience step to facilitate the transfer.

• 2016-06-15 — Reel not retrieved

  • Conveyance: Assignment of Interest
  • Assignor: Lancope LLC
  • Assignee: Cisco Technology, Inc.
  • Correspondent: ⚠️ not retrieved
  • Context: Acquisition close-out — title transferred to Cisco Technology, Inc. as part of the $452.5M Lancope acquisition.

(No further recorded assignments after 2016-06-15 surfaced. The patent is listed as Expired – Lifetime, adjusted expiration 2024-05-05.)

Timeline diagram

timeline
    title Ownership of US 7185368
    2001 : Copeland assigns to Lancope Inc
    2005 : Security agreement Venture Lending
    2008 : Security agreement Silicon Valley Bank
         : Security agreement Partners for Growth
    2009 : Release by Venture Lending
         : New SVB security agreement
    2014 : Updated SVB security interest
         : Lancope Inc internal merger
    2015 : Cisco agrees to buy Lancope
         : Partners for Growth lien released
    2016 : SVB liens terminated and released
         : Lancope Inc renamed Lancope LLC
         : Assigned to Cisco Technology Inc
    2024 : Patent expires

NPE / troll-pattern signals

1. Shell-entity transfer — Not present. The chain runs operating company → operating company (Lancope, Inc. → Cisco Technology, Inc.). "Lancope LLC" is the product of a documented Change of Name (2016-06-08), not a new licensing shell, and Cisco is a large operating company. No registered-agent-service address, no licensing-only LLC appears.

2. Known asserter in the chain — Not present. No assignee in the chain matches any entity on the referenced NPE lists (Acacia, Marathon, IV, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, etc.). Cisco Technology, Inc. is an operating networking vendor, not an NPE.

3. Repeat correspondent across the chain — Unclear (data not retrievable). I could not obtain the correspondent-of-record for any recording in this session, so I cannot test for a recurring attorney/firm. This is the one signal the task most wants and the one I am least able to assess — it requires the live Assignment Center reel/frame detail, which I could not pull. Do not read the "repeat correspondent" question as answered either way.

4. Cascading transfers — Not present. The 2014–2016 sequence is (i) a same-name internal Merger, (ii) lien releases, (iii) a name change, and (iv) the single acquisition close-out to Cisco — none of these are consecutive transfers through unrelated chained LLCs. No common-principal LLC hopscotch.

5. Pre-litigation transfer — Not present / unclear. The only title transfer (2016-06-15 to Cisco) is tied to the 2015 acquisition, not to a lawsuit. I found no infringement suit naming US 7,185,368 as an asserted patent; in the public record it appears as prior art in Cisco's IPRs (e.g., Cisco Systems v. Centripetal Networks, IPR2018-01654/01655, Exhibit 1006; and IPR2023-00554 re Orckit), where Cisco is the petitioner, i.e., using the patent defensively. So there is no "assignment within 6 months before first suit" pattern.

6. Bankruptcy fire-sale — Not present. Lancope exited via a $452.5M trade sale to Cisco (Oct. 2015), not a Chapter 7/11 liquidation.

7. Privateering — Not present. Cisco acquired Lancope's entire business (products, team, and portfolio) — a strategic merger, not a transfer to a separate NPE that asserts on the operating company's behalf.

8. Defensive aggregator (anti-NPE) — Not present. The chain terminates at Cisco Technology, Inc., an operating company, not at RPX, AST, LOT, Unified Patents, or OIN. The patent is not neutralized by a defensive aggregator.

Verdict

Operating-company assertion.

Justification (2–3 sentences): The ownership chain is a clean operating-company lineage — inventor Copeland → Lancope, Inc. (2001-11-30 assignment), through security-interest/release filings (Venture Lending 2005, SVB and Partners for Growth 2008–2014, released 2009/2015/2016) and an internal merger (2014-06-02) and change of name to Lancope LLC (2016-06-08), ending with the 2016-06-15 assignment to Cisco Technology, Inc. as part of the $452.5M acquisition. Every assignee is an operating entity, no listed-NPE or shell-LLC appears, and the current assignee (Cisco) ships products that embody the claims (Cisco Secure Network Analytics / StealthWatch), which is the definition of an operating-company-held patent rather than an NPE asset. Caveat: I could not confirm that Cisco has affirmatively asserted this patent against a competitor — publicly, 7,185,368 surfaces as prior art in Cisco's IPRs — and because the correspondent-of-record and reel/frame data were not retrievable, the "repeat correspondent" and precise transaction metadata remain unverified.

Verify the record at: USPTO Assignment Center (search patent 7,185,368) — this is the authoritative source for the reel/frame numbers and correspondents I was unable to retrieve.

Data gaps to close (do not treat as findings)

• Reel/frame for all 12 recordings — not retrieved.
• Correspondent of record for all 12 recordings — not retrieved (blocks signal #3).
• Execution dates vs. the recorded dates shown — only record dates available.

I did not fabricate any assignment, reel/frame, or correspondent. Where the data was unavailable, it is marked as such.

I'll research the prior art citations for US 7,185,368 specifically. Let me start with targeted searches.

I have the patent's cited-references list. Let me now pin down filing dates and identities of the key references, especially the PCT publications and the older U.S. patents.

I have the reference list and confirmed several dates. Let me pin down the remaining PCT, the issued claim set, and the key older references.

Prior-Art Analysis — US Patent 7,185,368 (Flow-Based Detection of Network Intrusions)

0. Scope, sources, and honesty flags (read first)

What I could and could not do. There is no direct USPTO PatentCenter/PAIR/Patent-Examining-Research API available to me in this session — only general web search. So I did not run a literal USPTO full-text query. Instead I relied on:

• the authoritative full patent text supplied in the task (Google Patents mirror of USPTO data, fetched 2026-09-24), which was truncated before the claims;
• the printed patent's front page ("References Cited"), which I recovered from (i) the Justia listing for 7,185,368 and (ii) a scanned copy of the granted patent used as an exhibit in PTAB proceedings (DocketAlarm, IPR2018-01655 Ex. 1006);
• corroborating hits for individual references.

Interpretation rule applied: every alphanumeric ID below is read literally. Where a source returned a different number I say so rather than silently "fixing" it.

Two flags you should carry through the whole document:

1. The claim set differs between the published application and the issued patent. The published application US 2003/0105976 A1 (app. 10/000,396) has 12 claims; the issued patent has 37 claims. Claim-by-claim §102 mapping for issued claims 1–29 is therefore incomplete in this report — I anchor to the claims I could verify (issued claims 30, 33, 35, 37 per the earlier section, plus the published-application claim text as a proxy for issued claim 1). This is an inference, not authoritative.
2. Most of the references cited on the face of 7,185,368 cannot possibly anticipate it. They were cited as background or as secondary references. Under §102 a single reference must disclose every limitation; several of the listed references also post-date the Nov 30, 2000 priority date and so are not §102 art at all against these claims. I mark each reference accordingly rather than implying anticipation that does not exist.

1. Bibliographic confirmation (high confidence)

(The "ctd." in the "References Cited" heading — "(56) References Cited U.S. Patent Documents" — is the standard front-page field.)

2. U.S. patent references cited on the face of 7,185,368

Dates below are issue dates, verified; filing dates are given only where I verified them, otherwise flagged. §102 status is stated relative to the Nov 30, 2000 priority / Nov 30, 2001 filing (pre‑AIA §102 governs — filed 2001).

3. Foreign patent documents

4. Non-patent literature cited

5. Which claim(s) each reference could potentially anticipate — consolidated

Anchor claims (issued): 1 (method: assign to flow → flow data from headers → assign CI → accumulate CI for host → alarm on threshold), 30 (method; "at least one port remains constant"), 33 (system; predetermined fixed CI), 35 (system; flow + host data structures, cumulative CI, memory + network interface), 37 (method; UDP data segment ≤ 2 bytes → store CI for the sending host → alarm).

Net conclusion on §102. Across the entire face-of-patent citation list, no single reference discloses all limitations of independent claims 1, 30, 33, 35 or 37. The features that appear absent from all cited references and that therefore appear to have carried the claims are: (a) a per-flow "concern index" that is a predetermined fixed value, (b) accumulation of that index across flows into a per-host record, (c) alarm on the host's cumulative index crossing a threshold, and (d) the ≤ 2-byte-UDP condition of claim 37. This is consistent with the patent's own background, which expressly distinguishes the Porras '338 profile-comparison approach.

6. "Most relevant prior art" — ranked

1. Copeland, J.A. et al., "IP Flow Identification for IP Traffic Carried Over Switched Networks," Computer Networks 31 (1999), pp. 493– — the inventor's own §102(b) publication; the closest art on flow identification from packet headers.
2. US 6,321,338 B1 — Porras et al., "Network Surveillance" (§102(e), filed Nov 9, 1998) — the closest functional NIDS art; the specification of 7,185,368 discusses it by name.
3. US 5,991,881 A — Conklin et al., "Network surveillance system" (§102(b)) — the archetypal network-surveillance/alarm patent.
4. US 6,119,236 A — Shipley, "Intelligent network security device and method" (§102(b), filed Oct 7, 1996) — externally corroborated as highly relevant to the Lancope family (cited as an "X" reference in WO 2006/127012 A3).
5. PCT/US99/29080 (WO 00/34847 A1) — Diep, "Computer network intrusion detection" (§102(b)) — generic pattern-matching IDS.
6. Javitz & Valdes, "The SRI IDES Statistical Anomaly Detector" (§102(b)) — baseline statistical-alarm art.

Best combined §103 attack (for completeness, since the question asked about §102): Copeland 1999 (flow identification) + Porras '338 (network statistics → suspicious activity → alarm) + Conklin '881 (network surveillance/alarm) — targeting claims 1 and 30, not the CI-accumulation/system claims 33/35.

7. Contradictions / uncertainties to carry forward

• Claim-set mismatch (flagged): published app. US 2003/0105976 A1 = 12 claims; issued 7,185,368 = 37 claims. The published-application text (claim 1: "assigning packets to a flow; collecting flow data from packet headers; analyzing … to assign a concern index value … maintaining an accumulated concern index …; issuing an alarm signal once the accumulated concern index has exceeded an alarm threshold value") is used here as a proxy for issued claim 1, but I could not confirm issued claims 1–29 verbatim this session. Earlier analysis listed the independent set as most likely 1, 6, 25, 30, 33, 35, 37 — still an inference.
• Number-look-alike hygiene: I excluded US 7,738,368 (a different, heavily litigated patent) throughout.
• OCR-mangled numbers corrected only against the Justia face-of-patent list (6,628,654 / 6,853,619 / 6,891,839); I did not substitute these into any analysis as if fetched for the wrong number.
• Unverified items: titles/descriptions for 5,437,244; 5,557,686; 5,796,942; 5,825,750; 5,970,227; 6,182,226; 6,275,942; 2004/0187032; and the entire PCT/US00/29490 document — these should be pulled from the USPTO/Espacenet record before being relied on.
• Priority-date divergence in third-party data: one aggregator lists 7185368's priority as 2000-11-29; the patent and Google Patents say Nov 30, 2000. The document controls.
• Status: 7,185,368 is Expired – Lifetime (adjusted expiration 2024‑05‑05), now held by Cisco Technology, Inc. This matters practically: expired claims can still be cited as prior art but cannot be the target of a live validity challenge.

Practitioner's bottom line: the examiner allowed 7,185,368 over this citation set, and nothing on the face of the patent is a clean §102 reference to the independent flow/CI claims. The three references worth a full claim chart are Copeland 1999, Porras '338, and Conklin '881 — and only to test the "flow identification + statistics + alarm" limitations, not the "concern index" limitations. Before relying on any specific reference, pull its official USPTO/Espacenet record (especially the unverified titles and PCT/US00/29490) so that each citation's dates and disclosure are confirmed rather than inferred.

I'll pull the prior-art reference list for US 7,185,368 and verify the key references before building the § 103 analysis.

Let me verify the substance of the most material cited references so the combinations are grounded.

Obviousness Analysis — US 7,185,368 B2 under 35 U.S.C. § 103

Patent: US 7,185,368 B2, "Flow-based detection of network intrusions" (Copeland, III) · App. 10/000,396 · filed Nov. 30, 2001 · priority to provisional 60/250,261 (Nov. 30, 2000) and 60/265,194 (Jan. 31, 2001) · issued Feb. 27, 2007 · expired 2024-05-05

0. Framing caveats (read first)

1. The patent is expired. This § 103 analysis is retrospective. It matters because the '368 patent is alive as prior art (it is relied on as an Exhibit in other parties' PTAB proceedings — IPR2018-01654/-01655, IPR2023-00554), and because validity is still litigated for pre-expiry damages periods and in related-family disputes.
2. Claim-text gap carried forward. Per the earlier section, the exact wording of independent claims 1, 6, and 25 is unverified in this session (the supplied full text truncated before the claims, and searches returned only claims 26–37). I analyze the verified independents — 30, 33, 35, 37 — and their dependents, and flag where a broad claim 1 would be even more exposed.
3. Source conflict flagged. A 2025–26 student "REEP" report (Scribd) attributes the '368 patent to Enterasys Networks, inventors Dietz/Hein/Weed, filed 26 March 2002, and describes a "Characterisation Index" baseline model. That is erroneous and contradicts the authoritative text (Copeland; Lancope; filed Nov. 30, 2001; "concern index"). Discard it. Likewise, the OCR of the US 7,512,980 front page garbles names ("Parras," "Lemmzeaux," "Ticka," "6,553,619") — do not quote that OCR as authority for reference identities.
4. Prior-art date discipline. Because priority runs to Nov. 30, 2000, a reference must qualify as of that date (§ 102(a)/(b) publication, § 102(e) U.S. filing, or § 102(g)). This matters: several references on the face of the patent (e.g., US 2002/0104017 Stefan; US 2002/0133586 Shanklin; the 2003 Mahoney paper) post-date the priority date and are not available for the '368 claims. My grounds below use only references that predate Nov. 30, 2000, or that have a pre-priority U.S. filing date.

1. Person of ordinary skill in the art (POSITA)

A POSITA here is someone with a B.S. in CS/EE (or equivalent) and ~2–4 years of experience in network security / network management, familiar with TCP/IP header formats (as described in TCP/IP Illustrated), with flow-export technology (NetFlow/sFlow/IPFIX), and with the published IDS literature of the mid-to-late 1990s (IDES/NIDES, EMERALD, GrIDS, Bro, RealSecure/NetRanger-type products). This is a routine-engineering art in 2000: the building blocks — flow records, statistical scoring, thresholds, alerts, firewall reconfiguration — were all individually known.

2. The prior-art landscape (References Cited on the face + Applicant-Admitted Prior Art)

The specification itself admits as prior art: (a) firewall filtering on source/dest address, port, protocol; (b) signature-based IDS; (c) anomaly-based IDS — expressly including "TCP/IP stack fingerprinting, half-open attacks, and port scanning"; (d) statistical-baseline anomaly detection (measure a baseline, alarm on deviation); and (e) US 6,321,338 to Porras et al., "Network Surveillance." That admission (Applicant-Admitted Prior Art, AAP) is itself § 103 evidence and dramatically narrows the field of "invention" to the arrangement of known elements.

3. Element mapping — what each reference supplies

4. Grounds of obviousness

Ground A — Porras '338 in view of IDES/Javitz-Valdes (and Smaha '742)

Covers: claims 30, 33, 35; likely claim 1 (if broad).

• Porras supplies every structural limitation: header-only reception, two-host session partitioning, port-based service identification, client/server determination, per-interval packet/byte statistics, and threshold-triggered response.
• What Porras does not literally say is that the flow is scored with a predetermined, heuristically fixed index rather than an adaptive statistical deviation. IDES/Smaha close exactly that gap: per-subject anomaly scores accumulated and compared to a threshold.
• Motivation (strong, and partly supplied by the patent itself): the applicant's own Background states the goals — scalability, no signature database, fewer false alarms. Porras' adaptive-profile approach is expressly criticized in the Background for the false-alarm/masking problem ("small amount of malicious activity is masked by the large amounts of highly variable normal activity"; "merely because the average FTP stream may be 3 megabytes … does not indicate that a 20 megabyte stream is an anomaly"). A POSITA reading that criticism has a concrete reason to substitute a fixed, per-event scored index for the adaptive-profile comparison — i.e., to arrive at the "concern index." That is a substitution of one known scoring technique for another, with a predictable result (KSR Int'l v. Teleflex, 550 U.S. 398 (2007)).
• Reasonable expectation of success: high; both references produce "suspicious/unusual activity" flags from header-derived statistics and both alarm on accumulated score.

Ground B — Porras '338 in view of the flow-export (NetFlow/sFlow) art, optionally with Trcka '345 or Vaid '131

Covers: claims 30, 33, 35 (and dependent flow-delimitation claims 31/32/34/36).

• NetFlow supplies, verbatim, the concept of a flow data structure: a cache of records keyed on addresses/ports/protocol carrying packet count, byte count, start/end times, expired on inactivity and exported. This maps onto the "flow data structure," "time of the first packet / time of the last packet," and the inactivity timeout flow-delimiter (the patent's 330-second timer is an admitted arbitrary/heuristically adjustable value).
• Porras supplies the client/server orientation (cl. 16) and the suspicious-activity logic; Trcka '345 supplies the passive, non-interfering monitoring placement (tap/promiscuous NIC).
• Motivation: routers were already exporting flow records for performance management; re-using them for security analysis is (i) the natural reuse of a known device for an additional, analogous purpose, (ii) driven by the acknowledged cost/scalability problem with signature systems, and (iii) a predictable improvement because the record fields a POSITA needs (IP pair, ports, pkts, bytes, times, TCP flags) are already in the exported record set.
• This is the strongest combination for the flow-delimiting dependents: NetFlow's inactivity-based flow expiry plus TCP RST/FIN session teardown (Porras ¶ 74–75; the patent's own RESET). 330 s, 6 min sweep, 5 min intervals are optimization of a known parameter and not inventive (In re Aller; KSR).

Ground C — Porras '338 + EMERALD/GrIDS-type correlation, in view of Conklin '881

Covers: the "host data structure" + accumulated CI + alarm, and the "inside/outside" host lists.

• The patent's distinctive move is aggregating per-flow suspicion into a per-host running total so that a distributed attacker's many weak signals sum to a strong one. Porras' hierarchical monitors and EMERALD's correlation of reports across monitors/hosts, plus IDES' per-subject accumulation, teach exactly the correlative architecture. Conklin '881 teaches real-time alerting and "incident progress analysis" from a monitoring console, supplying the alarm/reporting limitation.
• Motivation: the patent's own stated problem is false alarms from single-event detection ("known anomaly based systems tend to generate an undesirable number of false alarms which creates a tendency to have all alarms generated to become ignored"). Aggregating evidence across events/hosts to suppress false positives is the classic, well-understood purpose of event correlation — a POSITA would apply it for its known function with predictable results.
• This ground also disposes of the "address scanning" dependent claim (CI added when a host contacts >N hosts in a subnet): Porras ¶ 76 already treats address scanning via ICMP/SYN to many destinations as suspicious; buffering a per-host list of contacted addresses and counting them is ordinary bookkeeping.

Ground D — Porras '338 in view of Shipley '236 (and, if verified, the packet-sampling/flow CIP art)

Covers: claims 30/33/35 and the broadest claim 1.

• The ISA's own "X" citation of Shipley '236 against claims 1–23 of the related CIP shows that an examiner already considered a flow/monitoring-and-alarm reference to be anticipatory of a near-identical claim set. That is powerful evidence that the '368 claims, which are broader than the CIP's (the CIP added packet sampling), read onto the cited art.
• ⚠️ Confidence limited: I could not open Shipley '236's text in this session. Before relying on Ground D as a primary rejection, pull US 6,119,236 in full and confirm its flow/statistics/alarm teachings.

Ground E — Claim 37 (short-UDP), standing alone or over AAP + Porras

Covers: claim 37; and any dependent claim reciting "UDP packet with a data segment of two bytes or less."

• The Background admits UDP-based anomalies and port-scanning as known anomaly attacks, and the patent's own narrative concedes that "a UDP packet with no appended data does not occur in normal communications." Porras ¶ 76 independently treats UDP-port scanning detected via ICMP "Destination Unreachable"/unused-port traffic as suspicious.
• The only arguably technical limitation in claim 37 is the numeric cut-off "two bytes or less." That is a selected threshold value with no asserted criticality — a design choice/heuristic tuning, which under KSR and In re Aller is insufficient for nonobviousness absent evidence that the specific value yields an unexpected result. The specification offers none (it says only that CI values are "derived heuristically").
• Same logic applies to all "predetermined value" limitations in Table I/II: assigning different point weights to different suspicious categories (10 for a port scan, 40 for a probe, etc.) is arbitrary weight selection, not an inventive step.

Ground F — Dependent claims generally

• Claims 31–32, 34, 36, 38+ (flow delimiters: inactivity, FIN, port traffic characteristics, RESET; enumerated categories: potential TCP probe, potential UDP probe, half-open attack, TCP/UDP stealth port scan, bad flags, short UDP, address scan, port scan): every one of these categories is explicitly enumerated in the patent's own Background as a known anomaly-based attack class ("TCP/IP stack fingerprinting, half-open attacks, and port scanning") and/or is present in Porras ¶ 74–76. Where the category is known and the detection logic is a simple counter/comparison (SYN count ≈ RST count; UDP count vs. ICMP port-unreachable count; SYN count vs. SYN-ACK count; same-src-port→different-dst-ports), the implementation is routine programming of a known heuristic.
• The three-thread architecture (packet classifier / flow collector / alert manager) and the periodic linear sweep are arbitrary software-partitioning choices: allocating functionality to concurrent threads and polling on a timer are predictable implementation decisions with no asserted unexpected benefit.

5. Anticipated patentee rebuttals and why they likely fail

Objective indicia: I found no evidence in the record of unexpected results, skepticism, licensing-due-to-the-claims, or a long-felt-but-unsolved need with a nexus to the specific CI-accumulation feature. The patent's own Background describes the need as long-felt and known, which cuts against nonobviousness when the solution is a recombination of known elements.

6. Bottom line

• Strongest ground: Porras '338 (AAP) + IDES/Smaha-type fixed-score accumulation + NetFlow-style flow records, with Conklin '881 for the alarm/reporting. This combination supplies every element of verified independent claims 30, 33, and 35, and would likely also reach a broad claim 1 if that claim tracks the abstract/summary (SI-1 flow from headers → CI → host total → threshold alarm).
• Claim 37 (short UDP) is the weakest claim on nonobviousness, but even so its only non-admitted content is the 2-byte threshold — a design choice.
• The '368 patent's real weakness is its own Background: it concedes that header-based filtering, signature IDS, anomaly IDS (including half-open attacks and port scanning), statistical baseline detection, and Porras' network surveillance were all known, and then claims the aggregation of header-derived flow suspicion into a per-host score. That is a textbook KSR combination — familiar elements, known functions, predictable result, with an articulated (indeed self-supplied) motivation.
• Confidence: High that a § 103 rejection is sustainable over Porras '338 in view of the statistical-scoring art for the verified independents; Moderate for reliance on Shipley '236 and for the substantive content of Vaid '131 and Mansfield 1999, which I could not open in this session.

Verification still required: (1) pull the issued claims 1, 6, and 25 in full (this is the single biggest gap — it determines how broad claim 1 is and whether claim 25's "utilization component" adds anything non-obvious); (2) pull US 6,119,236 (Shipley) full text and confirm the ISA's X-citation basis; (3) confirm the effective filing dates of Vaid '131 and Trcka '345 for § 102(e) purposes; (4) confirm the provisional 60/250,261 actually supports the CI-accumulation limitations (if it does not, the priority date shifts to Jan. 31, 2001 or Nov. 30, 2001, opening up additional 2000–2001 art).