US 7095716

I'll run a few targeted searches, then reconcile them with the authoritative full text you provided.

Let me check for any litigation or PTAB matters specifically involving this patent as an asserted patent.

Bottom line up front

I can give you an authoritative summary of US 7,095,716 B1 because the full grant text was supplied and my searches corroborate it. Two caveats on the "search USPTO database and CAFC 2026 dockets" instruction:

• I do not have direct API access to USPTO PatentCenter/PTAB (PTACTS) or the CAFC/PACER docket systems. What follows is based on web search results plus the authoritative grant text; a live docket check should be run before relying on the negative litigation finding.
• Searches returned no CAFC 2026 docket and no district court case in which US 7,095,716 is the asserted patent. The only 2026-adjacent hit tied to this number is a PTAB matter in which the '716 patent is used as prior art, not as the patent-in-suit (see "Litigation status" below). Treat that negative as search-limited, not as a certification.

Bibliographic data (verbatim from the grant text)

Family (same priority, 2001-03-30): US 7,602,775 B1 (continuation, "Internet security device and method"); US 8,068,487 B1 and US 8,654,779 B1 ("Network security device and method"); US 9,385,994 B2 ("Network security device"). The '716 line has thus expired; the later members are also shown as expired/expired-fee-related.

Data discrepancies worth flagging (do not silently reconcile):

• The Unified Patents portal lists priority 2001-03-29, application date 2002-03-27, grant date 2006-08-21 — each exactly one day earlier than the grant/Google Patents values. This is likely a time-zone/EPO-convention artifact, but I am reporting both rather than auto-correcting.
• The retrieved claim text contains apparent digitization anomalies (e.g., claim 3's "if when the data packets are not IP packets," claim 7's "an or access policy checks," claim 18's "if the data packet is an IP packets"). These look like OCR/HTML-conversion artifacts in the copy I was given and/or in the public mirrors. Exact claim wording should be confirmed against the USPTO official copy before any claim-charting or validity work.

Abstract (as printed)

Methods and apparatus, including computer program products, implementing and using techniques for processing a data packet. An input port receives a data packet, a switching board classifies the data packet, determines whether the data packet should be accepted, and switches the data packet to a management board if the data packet is a first data packet in a session, and to a processing board if the data packet is not a first data packet in a session. A management board receives a data packet from the switching board, examines the data packet and forwards the data packet to one of the processing boards. One or more processing boards receives non-first data packets from the switching board and data packets from the management board and processes the data packets. A firewall and a secure gateway with firewall and virtual private network functionality for processing a data packet are also described.

What the patent actually discloses (architecture)

The device is a chassis of boards on an internal bus: switching board (205), management board (210), I/O board (215), and multiple processing boards (220), all modular and user-expandable to add throughput.

• Switching board: packet pre-processing (IP or not), layer 2–4 extraction (VLAN ID, IP src/dst, protocol number, IP ID, TCP/UDP ports, ESP/AH SPI, PPTP/L2TP call ID), a session table lookup, and a fragment trace queue so that non-first IP fragments bypass the control path and go straight to the correct processing board. Priority queuing (configurable) provides QoS. Outgoing traffic (Fig. 5) is split via an L2 FIFO/splitter that also recognizes "session control packets" carrying a special MAC type value.
• Management board (slow/control path): handles the first packet of a session plus anything not directly switchable — L2 decapsulation/VLAN check, non-IP handling (ARP, NSRP), firewall check (e.g., port scan, ping-of-death, logged), dynamic port database check (e.g., FTP POR-created data sessions, with aging-out), access policy check, self-addressed/"check for self" → IP stack, TTL/special handling, then session creation and load-balanced assignment to a processing board (lowest/even load), with session state pushed to the switching board and to HA peers.
• Processing boards (fast/data path, parallel): ingress tunnel lookup and IPSec decapsulation, IP firewall attack check, local session table lookup, stateful inspection, egress self-check/IKE, NAT/PAT, egress tunnel encapsulation, and traffic management (priority/bandwidth pools). Boards are identical physically and in firmware so one can take over for a failed peer; an unrecognized packet is returned to the management board.

The stated advantage is a high-performance, stateful-inspection firewall + VPN platform whose parallel processing and encryption acceleration avoid the throughput bottleneck the background attributes to conventional security appliances.

Independent claims in plain language

Claim 1 — Device (the generic architecture claim). Apparatus with four functional blocks: (a) an input port that receives the packets; (b) a switching board that classifies packets, decides whether they should be accepted, and decides whether each is the first packet of a session; (c) a management board that gets only the packets the switching board identified as first-in-session, examines them, and forwards them onward; and (d) one or more processing boards that get both (i) the non-first packets straight from the switching board and (ii) the packets forwarded by the management board, and process both streams.

Claim 16 — Firewall device. Same receive/classify/accept/first-in-session split and same switch-to-management-or-processing routing, but with the added requirements that the management board performs a firewall check on the packet it receives, and that the processing boards receive the packet from the switching board when it is not the first in session and from the management board when it is.

Claim 17 — Secure gateway (firewall + VPN). Same structure as claim 16, with the additional element that the processing boards' processing includes encrypting and decrypting virtual private network traffic.

Claim 18 — Internet security device (integrated, "kitchen-sink" claim). Pulls several dependents up into one independent claim: the switching board classifies by determining whether the packet is an IP packet, decides acceptance, and decides first-in-session; it switches to the management board if the packet is first-in-session or not an IP packet, and to a processing board if it is non-first-in-session or is an IP packet; the management board examines the packet by performing a firewall check, a dynamic port database check, and/or an access policy check, and forwards it to a processing board selected on a user-customizable criterion; the processing boards take non-first packets from the switching board and packets from the management board and process them.

⚠️ Flag: the "or if the data packet is an IP packets" alternative in claim 18, as it appears in the retrieved text, contradicts dependent claim 3 (switching non-IP packets to the management board) and claim 6. I am not auto-correcting it; it may be an OCR artifact or a genuine drafting/amendment artifact in the granted claim. Verify against the official copy before relying on it.

Claim 19 — Method in a security device. Receive the packet; classify it to decide whether it should be accepted by the security device; determine whether it is the first packet in a session; examine the packet only if it is first-in-session to decide acceptance; switch it to the management board if first-in-session and to a processing board if not; and process it in the device if it is accepted.

Dependents in brief: claim 2 (IP-packet classification), 3 (non-IP → management board), 4 (extract IP info; first-in-session determination), 5 (VLAN/IP addresses/protocol no./IP ID/transport-layer info), 6 (non-first fragments routed via fragment trace queue entries), 7 (firewall / dynamic-port-database / access-policy checks), 8–9 (load-based forwarding, lowest-load board), 10 (user-selected criterion), 11 (board counts user-configurable), 12 (checks user-configurable), 13 (device is an Internet security device), 14 (two or more processing boards operating in parallel), 15 (policy enforcement, VPN enc/dec, key negotiation, firewall, NAT, tunnel encap/decap, inter-board hot backup).

Prior art of record and citation footprint

• Cited by the examiner (2 references, both AMD): US 6,798,788 B1 ("Arrangement determining policies for layer 3 frame fragments in a network switch," 1999-11-24) and US 6,950,434 B1 ("Arrangement for searching packet policies using multi-key hash searches in a network switch," 1999-12-07). These map directly onto the two most distinctive aspects of the '716 disclosure (fragment handling and policy/session lookup).
• The patent is itself heavily used as prior art. It appears as an exhibit in PTAB proceedings, e.g. Ex. 1012 (U.S. Patent No. 7,095,716) in IPR2022-01421, Keysight Technologies, Inc. v. Centripetal Networks, LLC (challenged patent US 10,681,009), filed Aug. 12, 2022 — docketalarm.com exhibit page; and in another Centripetal-related petition it is cited as "U.S. Patent 7,095,716 ('Ke')" as Ex. 1010 in a § 103 combination with Law, Golnabi, Jungck and/or Johnson.
• 33 family-level pre-2001 references include the Lucent firewall family (US 6,154,775; 6,141,749; 6,098,172; 7,143,438; 6,170,012), the Cisco "forwarding agent" family (US 6,549,516; 7,051,066; 6,650,641; 6,742,045; 6,970,913; 6,735,169; 6,606,315; 6,704,278), Cisco's US 6,928,482 (parallel packet-processor load balancing), and Sun's US 6,263,368 (network load balancing by packet counting). These are the most probative obviousness references if the patent were ever re-challenged.

Litigation status (as searched, with uncertainty noted)

• No CAFC 2026 docket was found in which US 7,095,716 is the patent on appeal. No district court complaint asserting the '716 patent was found. The patent is expired (adjusted expiration 2024-11-08), so future assertion is not possible for the '716 itself.
• The only live-looking thread: the CAFC September 2026 argument calendar lists 25-1052, PTO, Centripetal Networks, LLC v. Keysight Technologies, Inc. — that appeal arises from the '009 patent (US 10,681,009) IPR in which the '716 was merely an exhibit. So '716 is present in the record as background art, not as the subject of the appeal.
• Date anomaly to note: the CAFC calendar document I retrieved is captioned "September 2026 (Revised August 19, 2026)," which post-dates the stated current date of April 26, 2026. I am reporting it as retrieved rather than reconciling the dates. A direct CAFC docket lookup on 25-1052 is advisable.

Explicit uncertainty: I have high confidence in the bibliographic data, abstract, disclosure, and claim structure for US 7,095,716 (backed by the grant text and corroborating mirrors). I have lower confidence in any negative claim about 2026 litigation, because I could not query CAFC/PACER directly, and I have deliberately not corrected the one-day-off date discrepancies among third-party databases or the apparent textual anomalies in the published claim set.

Sources: https://patents.google.com/patent/US7095716/en · https://portal.unifiedpatents.com/patents/patent/US-7095716-B1 · https://www.docketalarm.com/cases/PTAB/IPR2022-01421/Keysight_Technologies_Inc._v._Centripetal_Networks_Inc/08-12-2022-Petitioner/Exhibit-1012-Ex_1012___US_Patent_No_7,095,716/ · https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1550164](/patent/1550164)/download-documents · https://www.cafc.uscourts.gov/wp-content/uploads/OralArguments/PublicCalendar-September2026.pdf

I'll research litigation involving US patent 7095716. Let me search multiple sources.

Let me search litigation-specific databases for this patent.

I found a key lead (the Juniper v. Palo Alto Networks litigation). Let me verify whether the '716 patent itself was asserted.

I'll verify the ODP default ("no PTAB activity") against web sources before writing this up.

The first pass surfaced only false positives (7095716 appearing as an exhibit, not as the challenged patent). Let me run more targeted checks.

Proceedings overview

Total AIA trial proceedings on US 7,095,716: 0. The structured PTAB block in the prompt states plainly that the USPTO Open Data Portal returns no AIA trial proceedings for this patent, and my independent web checks (Google Patents family/legal-status data, PTAB docket aggregators, PTAB E2E document hits, and litigation-reporting sources) surfaced no IPR, PGR, or CBM naming US 7,095,716 as the challenged patent — no institution decisions, no Final Written Decisions, no terminations, no Federal Circuit appeals. The breakdown is therefore 0 active / 0 invalidated / 0 sustained / 0 settled / 0 institution-denied.

Defensive posture this gives a defendant: the patent is untested, not hardened. Nothing has narrowed it, but nothing has confirmed it either — there is no free invalidity kill, and no claim has been canceled that you can point to. Critically, you likely do not need an IPR defense at all: the patent and every member of its family are expired (US 7,095,716 adjusted expiration 2024-11-08, status "Expired - Lifetime"), so any live assertion today would have to be a back-damages claim for pre-expiration conduct, or would have to be based on a different patent in the family. If a demand letter cites US 7,095,716 for ongoing/present conduct, the timing is your first and strongest objection (§ 286 six-year lookback plus expiration).

No proceedings to report — with the verification trail

No AIA trial proceeding on file for US 7,095,716

• Type: n/a
• Filed: n/a
• Status: Verbatim from structured data: "The USPTO ODP API returns no AIA trial proceedings for this patent as of the most recent ingest." Plain-English gloss: no petition has ever been filed against this patent at the PTAB.
• Judge panel: n/a
• Petition grounds: n/a
• Institution decision: n/a
• Final Written Decision: n/a — no claim of US 7,095,716 has been canceled, confirmed, or construed by the Board.
• Settlement / termination: n/a
• Appeal: n/a
• Defensive value: You cannot get a cheap PTAB win here, and you don't need one to establish invalidity later — but you also have no FWD to cite as estoppel or as a merits finding. Any invalidity fight must be run in district court (or as a reexam), on a clean slate, and you should check whether the asserted claims are even live given the 2024-11-08 expiration.

False positives I checked and ruled out (do not cite these as proceedings against 7095716)

• IPR2023-00703 and IPR2023-00673 — Cisco Systems, Inc., Palo Alto Networks, Inc., and Fortinet, Inc. v. Lionra Technologies Ltd. These appear in Google Patents' "related proceedings" data near a 7095716 reference, but the challenged patents are US 7,685,436 B2 and US 8,566,612 B2 ("System and method for a secure I/O interface," Davis et al.) — not 7095716. Cisco settled out by Board order (July 2024) and was terminated under 35 U.S.C. § 317; Palo Alto Networks and Fortinet remained as petitioners. Source: Board Order terminating Cisco (IPR2023-00673 / IPR2023-00703).
• IPR2022-01421 — Keysight Technologies, Inc. v. Centripetal Networks, Inc. US 7,095,716 appears here only as Petitioner's Exhibit 1012 — i.e., it was submitted as prior art, not challenged. Source: Ex. 1012, US Patent No. 7,095,716.
• IPR2021-01521 — Palo Alto Networks v. Centripetal and a Lionra reexamination record (App. 12/697,112) both list 7095716 among citation strings. Again, citation-as-art, not challenge.
• IPR2024-00158 likewise traces to the Lionra '612 patent, not 7095716.

I also searched for any IPR by Juniper-adjacent challengers (Palo Alto Networks, Fortinet, Cisco) naming this patent and found none. If a proceeding exists that ODP has not ingested and that no public docket aggregator has indexed, it is not discoverable from open sources — which would itself be extraordinary for a case that reached an institution decision.

Strategic summary

Claim-by-claim status — all 19 claims UNTESTED. Claims 1–19 of US 7,095,716 have never been before the Board. Claims 1 and 18 are the two principal independent device claims; claim 16 (firewall device), claim 17 (secure gateway with firewall + VPN functionality), and claim 19 (method) are the other independents. None is canceled, none is confirmed by a merits panel, none has been amended in an AIA trial. Contrast this with the family: the continuation US 7,602,775, and the later US 8,068,487, US 8,654,779, and US 9,385,994 all carry the same 2001-03-30 priority and are also "Expired." If someone is asserting "the Juniper/Netscreen firewall patent family," verify which patent number is in the letter — 7095716's claim set is the untested original.

Estoppel landscape — there is effectively none, in either direction. Because no petitioner ever filed against 7095716, § 315(e)(2) estoppel has never attached to anyone. That cuts both ways: any accused infringer retains the full universe of § 102/§ 103 prior art (including the NetScreen-era documentation that appears repeatedly in this family's prior-art record — e.g., the NetScreen Command Line Reference Guide (2000) and NetScreen Concepts and Examples ScreenOS Reference Guide (1998–2001), which were used as exhibits in related Lionra/Secure-I/O-interface matters). Nothing is barred, nothing is "reasonably could have raised" — the slate is clean. The corollary: you cannot piggyback on a prior petitioner's win, because there isn't one.

Pattern signals — the absence is the signal. This is a 2001-priority, Juniper-owned patent that issued 2006-08-22 and expired 2024-11-08. It was never asserted in a way that attracted a single IPR, despite Juniper itself being a serial petitioner (e.g., Juniper v. Implicit, Juniper v. Packet Intelligence, Juniper v. Monarch Networking, Juniper v. Orckit) and despite the family being litigated at the edges (the Implicit v. Juniper line involved a related Netscreen flow-based/session-processing disclosure). No defensive aggregator (Unified Patents or similar) is in the chain visible for 7095716 — Unified's portal page for the patent shows no challenge activity. The most plausible reading: by the time IPR practice matured (2012+), the patent's commercially relevant life was already closing, and any disputes were run against sibling patents with longer remaining term.

Recommended next steps

1. Lead with expiration, not invalidity. US 7,095,716 is "Expired - Lifetime" with an adjusted expiration of 2024-11-08 (Google Patents legal status). Confirm against USPTO Patent Center for 10/112,924 and pull the maintenance-fee history; if the patent lapsed earlier for fee reasons, the damages window may be even shorter. Combine with the 35 U.S.C. § 286 six-year damages lookback.
2. Identify the patent actually being asserted. Demand letters in this space routinely quote the family's shared specification. Get the exact patent number; the continuation line is US 7,602,775 → US 8,068,487 → US 8,654,779 → US 9,385,994. If a sibling is asserted, rerun this PTAB analysis on that number — my searches here did not isolate AIA trials on those siblings, but I did not verify each one, and you should not assume zero.
3. If invalidity must be shown, do it in court or via ex parte reexamination. No § 315(b) time bar applies (no served complaint history found), so an IPR against an unexpired sibling remains technically available — but for 7095716 itself, an IPR would be of limited practical value given expiration, and the Board would not permit claim amendments by an expired-patent owner. A district-court § 282 defense or a reexam request citing the NetScreen ScreenOS 2.5 documentation is the more efficient path.
4. Note for completeness: uspto.report flags a Certificate of Correction on this patent. I have not reviewed its contents and will not characterize it — obtain the certificate from Patent Center before relying on any claim text. (Independent one-line of caution: the printed claim 7 has an apparent scrivener's error — "firewall checks, dynamic port database checks, and an or access policy checks" — which a certificate may address.)

Bottom line for a defendant today: there is no PTAB proceeding on file for US 7,095,716 — no institution decision, no FWD, no appeal, no settlement. That is a verified zero, not a gap. Your motion to dismiss / non-infringement posture should lead with the 2024-11-08 expiration and § 286, and reserve invalidity for the district court, where no estoppel constrains you.

I'll research the assignment record for US 7095716. Let me start with several targeted searches.

Let me get the detailed assignment records and check for any downstream transfers.

Ownership Analysis — US 7,095,716 B1 ("Internet security device and method")

Patent: US 7,095,716 B1 · App. 10/112,924 · Filed 2002-03-28 · Granted 2006-08-22
Provisional priority: 60/280,684, filed 2001-03-30
Status: Expired – Lifetime (adjusted expiration 2024-11-08)

Verification entry points: USPTO Assignment Center and the legacy Assignment Search (search by patent number 7095716). Note the two searches do not always render identically; the legacy interface exposes reel/frame and correspondent fields that the newer UI sometimes hides.

Inventors

Determination of employer: The application was filed by NetScreen Technologies, Inc. as applicant/owner, and the inventors' assignment of rights to NetScreen Technologies, Inc. was recorded 2002-06-19 (see Legal Events, Google Patents). The sibling PCT filing (WO 02/079949 A3, PCT/US02/09876) lists "NETSCREEN TECHNOLOGIES, INC., 350 Oakmead Parkway, Sunnyvale, CA 94085" as applicant. Inventor Yan Ke is publicly identified as a NetScreen co-founder (alongside Feng Deng), which corroborates that the named inventors were NetScreen personnel rather than outside contractors.

Unusual-pattern check — negative. There is no 12-month post-filing inventor exodus evidenced here. The inventors remained within the NetScreen organization through the Juniper acquisition (completed 2004-04-19), and no reissue, correction, or re-assignment of the inventors' interests appears in the record. This is a normal corporate-employee invention assignment, not the front end of a fire-sale.

⚠️ Caution for downstream analysts: WO 02/079949 names a different inventor set (Ke, Mao, Wu, Yean-Shiang Leu) for a related but distinct "Internet security system" filing. Do not merge that inventorship into the '716 chain.

Original assignee

NetScreen Technologies, Inc. (Sunnyvale, CA) — assignee of record as applicant; the printed patent front page carries Juniper Networks, Inc., Sunnyvale, CA as assignee because the NetScreen → Juniper assignment was recorded before grant.

• Product embodying the claims: Yes. NetScreen shipped firewall/VPN appliances (NetScreen-5/25/50/204/208, NetScreen-IDP, NetScreen-SA series running ScreenOS) that practice the claimed multi-board packet-classification/stateful-inspection architecture. NetScreen products were later identified in PTAB papers as prior art with a public use date "at least as early as July 9, 2002," confirming they were in commerce during prosecution.
• Primary line of business: Network security appliances (firewall, VPN, IDP) for enterprises and carriers.
• Current status: Acquired. NetScreen was acquired by Juniper Networks, Inc. in an all-stock deal announced 2004-02-09/10 and completed 2004-04-19 (≈ $3.4–4B). NetScreen ceased to exist as a separate entity; its business continues as Juniper's security product line. No bankruptcy, no dissolution, no fire-sale.

Assignment timeline

Two conveyances are recorded against this patent. Both are routine corporate ownership instruments; neither is an NPE instrument.

• 2002-06-19 (recorded) / execution date not retrieved — Reel not retrieved (recorded as a NetScreen "ASSIGNMENT OF ASSIGNORS INTEREST" event, per Google Patents Legal Events)

  • Conveyance: Assignment (Assignment of Assignors' Interest)
  • Assignor: HUANG, Guangsong; KE, Yan; MAO, Yuming; TONG, Jian (the four named inventors, individually)
  • Assignee: NetScreen Technologies, Inc.
  • Correspondent: Not retrieved. The Assignment Center abstract of title carries a correspondent field for this recording, but it did not surface in any source I was able to fetch, and I will not guess at an attorney name or firm. This is the one open data gap in the chain — it is the single field most worth pulling directly from Assignment Center, since it would name NetScreen's prosecution/assignment house at the time (the PCT lists Fish & Richardson P.C., Redwood City, as agent of record, but that is the prosecution agent, not necessarily the assignment correspondent — do not conflate the two).
  • Context: Standard employee invention assignment — initial vesting of title in the operating company.
  • Recurrence flag: Cannot be assessed — correspondent unavailable.

• 2004-06-17 (executed) / recorded 2004-06-19 — Reel 14743/842 (USPTO Patent Assignment Abstract of Title; indexed at Plainsite as Assignment ID 2761376)

  • Conveyance: Assignment of Assignors' Interest
  • Assignor: NetScreen Technologies, Inc.
  • Assignee: Juniper Networks, Inc., 1194 N. Mathilda Ave., Sunnyvale, CA 94089
  • Correspondent: Not retrieved from available sources (see gap note above).
  • Context: Merger cleanup — confirmatory recordation of the NetScreen-into-Juniper merger completed 2004-04-19, executed two months later to perfect the chain of title on the file. Not a privateering transfer, not a portfolio divestiture: the acquirer is the same operating company that absorbed the whole NetScreen business.

No further assignments are of record. No security agreement, no release, no corrective assignment, no transfer to any Acacia / Marathon / IV / Wi-LAN / Pendrell / Monarch / Starboard-type vehicle, and no defensive-aggregator assignment (RPX / AST / Unified / OIN) appears against US 7,095,716. The patent remained with Juniper Networks, Inc. until expiry.

Corroborating portfolio behavior: Juniper filed a chain of continuations claiming this priority date — US 7,602,775 B1 (2006), US 8,068,487 B1 (2009), US 8,654,779 B1 (2011), and US 9,385,994 B2 (2014) — all held by Juniper Networks, Inc. A party planning to sell or assert a family does not normally keep filing fresh continuations into it for thirteen years.

Litigation check — this patent is a cited reference, not an asserted patent. US 7,095,716 appears as Exhibit 1012 in IPR2022-01421 (Keysight Technologies, Inc. v. Centripetal Networks, Inc.) and in the '358 invalidity record, i.e., as prior art being charted against other parties' patents. The PTAB exhibit copy shows "(73) Assignee: Juniper Networks, Inc., Sunnyvale" — confirming title was still with Juniper at the time. US 7,095,716 is not itself the patent-in-suit in any proceeding I found; the many "Acacia / Starboard / Monarch" reel citations returned in search belong to wholly unrelated patents (e.g., app. 12/528,083) and must not be attributed to this patent.

Timeline diagram

timeline
    title Ownership of US 7095716
    2001 : Provisional filed by NetScreen
    2002 : Non-provisional filed
         : Inventors assign to NetScreen
    2004 : NetScreen merges into Juniper
         : Merger confirmed at reel 14743 frame 842
    2006 : Patent granted to Juniper
         : Continuation filed
    2009 : Continuation filed
    2011 : Continuation filed
    2014 : Continuation filed
    2024 : Patent expired

NPE / troll-pattern signals

1. Shell-entity transfer — not present. No assignment to any entity with an "IP / Patents / Licensing / Holdings / Ventures" suffix. The only two recorded links are inventors → NetScreen and NetScreen → Juniper (reel 14743/842). Both are operating companies; neither is a single-purpose LLC.

2. Known asserter in the chain — not present. Neither NetScreen Technologies, Inc. nor Juniper Networks, Inc. appears on any public NPE list, and no Acacia / Marathon / IV / IPNav / Wi-LAN / Conversant / Vringo / Pendrell / Innovatio / MPHJ / Lumen View / Round Rock / Spangenberg vehicle appears in the reel history of this patent. Current assignee remains Juniper Networks, Inc.

3. Repeat correspondent across the chain — unclear (data gap). The correspondent-of-record for neither reel 14743/842 nor the 2002-06-19 NetScreen recording was retrievable from the sources I could fetch. Because the signal is defined by recurrence, a single unknown or single appearance would not be a finding anyway; flagged as unclear pending direct retrieval from Assignment Center.

4. Cascading transfers — not present. Longest chain is two links, spanning 2002–2004, and the second link is a merger confirmation rather than a cash assignment. There is no chained-LLC sequence anywhere in the record.

5. Pre-litigation transfer — not present. No infringement suit naming US 7,095,716 was found, so there is no litigation date to measure a transfer against. The 2004 recording predates grant (2006) and reflects a corporate merger, not litigation preparation.

6. Bankruptcy fire-sale — not present. NetScreen was acquired at a premium in a solvent, all-stock merger (announced Feb 2004; completed 2004-04-19). No Chapter 7/11 proceeding, no §363 sale, no stalking-horse or credit-bid transfer is associated with this patent.

7. Privateering — not present. The transferor (NetScreen) ceased to exist as an independent entity upon the transfer; there is no operating company retaining an economic interest while an NPE asserts against its competitors. No SEC disclosure or third-party coverage links this patent to an off-balance-sheet assertion program.

8. Defensive aggregator (anti-NPE) — not present as a recorded event, but functionally similar in effect. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. It terminates at Juniper Networks, Inc. — a large operating company with a defensive portfolio posture (Juniper is publicly associated with patent-risk-sharing regimes such as LOT Network). The patent is now expired, so it is neutralized in practice, but not by any recorded defensive-aggregator assignment.

Verdict

Defensive / non-asserting.

The chain is exactly two recorded links — the four named inventors to NetScreen Technologies, Inc. (recorded 2002-06-19) and NetScreen Technologies, Inc. to Juniper Networks, Inc. (executed 2004-06-17, recorded 2004-06-19, reel 14743/842) — and the second link is a confirmatory recordation of the NetScreen-into-Juniper merger closed 2004-04-19. No shell entity, no known asserter, no chained LLCs, no bankruptcy, no privateering, and no litigation against this patent appear anywhere in the record; the patent expired 2024-11-08 still titled to Juniper. Caveat on the label: the rubric defines this category as terminating at a defensive aggregator, and this patent does not — it terminates at an operating company. It is nonetheless the correct non-NPE call, because there is no assertion evidence and the asset is expired, so it is non-asserting; the only residual uncertainty is the correspondent-of-record and the execution date/reel for the 2002-06-19 inventor assignment, both of which should be pulled directly from Assignment Center before this analysis is treated as final.

Verify: USPTO Assignment Center · Assignment Search by patent number (query 7095716) · recorded merger assignment abstract: reel 14743 / frame 842.

I'll research this systematically. Let me start by verifying the patent in USPTO databases and gathering details on each cited reference.

Let me gather details on the most relevant family-cited references (these were cited during prosecution of the patent family) and confirm the USPTO record.

Prior Art Analysis — US 7,095,716 B1 ("Internet Security Device and Method")

1. Confirmation of the USPTO record

The patent identified is US 7,095,716 B1, not a similar number. Key bibliographic data (confirmed via Google Patents, the granted-PDF exhibit filed in IPR proceedings, and Unified Patents):

Sources: https://patents.google.com/patent/US7095716/en ; https://portal.unifiedpatents.com/patents/patent/US-[7095716](/patent/7095716)-B1 ; granted PDF copy at https://www.docketalarm.com/cases/[PTAB](/ptab)/IPR2018-01506/Cisco_Systems_Inc._v._Centripetal_Networks_Inc/docs/08-10-2018-Petitioner/Exhibit-1015-Ex_1015_US_Patent_7,095,716_Ke.pdf

Important scope note on "citations": The face of the '716 patent lists only two U.S. patent citations (the references considered by the examiner during prosecution of 10/112,924). A broader set of 33 references appears in the Google Patents "Family Cites Families" field — but those were cited during prosecution of related family members (US 7,602,775; US 8,068,487; US 8,654,779; US 9,385,994), not necessarily during prosecution of the '716 itself. I treat the two face citations as the primary prior art and the family citations as a secondary pool, and I flag this distinction below. I have not verified every family-citation date against a primary source; where I rely on Google Patents index data I say so.

2. The two references cited on the face of US 7,095,716

2.1 US 6,798,788 B1 — "Arrangement determining policies for layer 3 frame fragments in a network switch"

• Full citation: US 6,798,788 B1; inventors Somnath Viswanath and Mrudula Kanuri (co-inventor listed elsewhere as Xiaohua Zhuang); assignee Advanced Micro Devices, Inc. (Sunnyvale, CA); U.S. Cl. 370/469.
• Dates: Provisional 60/167,218 filed Nov. 24, 1999; application filed Jan. 14, 2000; issued Sep. 28, 2004. (Pre-dates the '716 priority date of Mar. 30, 2001.)
• Description (from the abstract/claim 1): A layer 2 / layer 3 network switch whose ports include a policy filter that extracts L3 and L4 information from a received layer 2 frame and derives a policy identifier. A flow identification module caches the L3 information plus the policy identifier from the first frame, then re-applies that cached policy to subsequent fragmented L3 frames that lack the L4 information needed for an independent policy lookup. Claim 1 recites: receiving a first frame with L3+L4 info → determining a policy identifier → receiving a second frame containing only a portion of the first L3 info → selecting the first frame's policy identifier for the second frame by correlation.
• Sources: https://patents.google.com/patent/US6798788 ; https://insight.rpxcorp.com/patent/[US6798788B1](/patent/US6798788B1) ; https://patentimages.storage.googleapis.com/c8/86/16/46d69ddc8cf3bd/US6798788.pdf

Potential § 102 claim mapping:

2.2 US 6,950,434 B1 — "Arrangement for searching packet policies using multi-key hash searches in a network switch"

• Full citation: US 6,950,434 B1; inventors Somnath Viswanath and Gopal Krishna; assignee Advanced Micro Devices, Inc. (current assignee listed as GlobalFoundries Inc.); U.S. Cl. 370/392.
• Dates: Provisional 60/169,296 filed Dec. 7, 1999; application 09/496,212 filed Feb. 1, 2000; issued Sep. 27, 2005 (expiration 2020). (Pre-dates the '716 priority date.)
• Description: A network switch port includes a "flow module" that generates two hash keys from L3 information — e.g., any two of IP source/destination address, TCP/UDP source/destination port — combines them into a packet signature, and searches an on-chip signature table indexing layer-3 switching entries. Claim 1 recites generating first/second hash keys from first/second L3 information, combining them into a signature, and searching a table for a matching L3 switching entry.
• Sources: https://patents.google.com/patent/US6950434 ; https://insight.rpxcorp.com/patent/[US6950434B1](/patent/US6950434B1) ; https://patentimages.storage.googleapis.com/c5/79/47/5ba28f3b1c42b5/US6950434.pdf

Potential § 102 claim mapping:

3. Family-cited references (secondary prior-art pool)

The following appeared in the "Family Cites Families" field of the '716 family. They were considered during prosecution of one or more related Juniper applications, and several are the most substantively relevant art to the '716's system-level claims because they disclose the management/front-end + parallel-processor load-balancing architecture. Dates below are the Google Patents index values; treat them as needing verification. The italicized notes give the likely claim impact.

4. Overall assessment

1. No single reference anticipates independent claims 1, 16, 17, 18, or 19. The distinguishing feature of the '716 — a three-tier board architecture in which a switching board triages traffic into first-packet-in-session (to a management board) vs. non-first-packet-in-session (straight to a processing board) — is not disclosed by either face-cited AMD switch patent (US 6,798,788; US 6,950,434), both of which are single-switch/ASIC references. Any § 102 challenge to the independent claims would require a different reference (e.g., the Cisco US 6,928,482 / US 6,742,045 family), and even then it would likely be a § 103 combination rather than clean § 102 anticipation.

2. The strongest § 102 candidate among the face citations is US 6,798,788 against claim 6 (fragment handling), and US 6,950,434 against claim 5 (extracted IP/L3-L4 field set). Both are genuine § 102(a)/(e) prior art by date (1999 priority vs. 2001 priority).

3. Claims 8 and 9 (load-based selection of a processing board; lowest-load selection) are the '716 claims most vulnerable to a single-reference attack, via US 6,928,482 B1 (processing-load-value-based packet-processor selection) — a family-cited Cisco reference. This is my highest-confidence anticipation-adjacent finding, though the board-level architecture wording still needs to be mapped.

4. Cross-reference to the litigation summary: The earlier section identified the Juniper v. Palo Alto Networks litigation and the Cisco/Keysight IPRs against Centripetal. I can confirm from the search results that the '716 patent itself was filed as an exhibit (Exhibit 1015) in Cisco v. Centripetal, IPR2018-01506, and as Exhibit 1012 in Keysight v. Centripetal, IPR2022-01421 (https://www.docketalarm.com/cases/PTAB/IPR2018-01506/... ; https://www.docketalarm.com/cases/PTAB/IPR2022-01421/...). In those proceedings the '716 was used as prior art against other patents, not as the challenged patent — consistent with, and not contradicting, the prior litigation summary.

Caveats and limitations: (a) This is a technical/analyst assessment, not a legal opinion on validity or infringement. (b) I have not reviewed the full prosecution histories of the child applications, so I cannot state definitively which of the 33 family-cited references were actually applied against claims resembling the '716 claims. (c) Exact filing/priority dates for the family-cited references are taken from Google Patents/Unified Patents index pages and should be verified against the USPTO PatentCenter record for each before being relied upon. (d) Anticipation requires every claim element in a single reference; where I have marked a reference as relevant to a claim, that is a mapping statement, not a conclusion that the reference discloses the entire claim.

I'll ground the obviousness analysis in the actual disclosures of the references listed in the "Prior Art" section of the patent page. Let me verify the key references.

Obviousness Analysis — US 7,095,716 B1 under 35 U.S.C. § 103

Building on the "Patent summary" and "Litigation summary" sections above. I do not repeat the bibliographic data, disclosure summary, or claim-by-claim plain-language mapping already produced. This section assumes that material.

0. Analytical frame and caveats

Why this is a hypothetical. Per the prior sections, the '716 patent is Expired – Lifetime (adjusted expiration 2024-11-08), and no complaint asserting it was found. This is therefore a retrospective validity/obviousness assessment, not a live-controversy opinion.

Governing law. The application was filed 2002-03-28 and claims benefit of provisional 60/280,684 (2001-03-30), so pre-AIA §§ 102/103 apply. The critical date for § 103(a) purposes is 2001-03-30 (subject to the caveat in the prior section that benefit requires the provisional to support the claims; if it does not, the critical date shifts to 2002-03-28 and additional art opens up).

Reference dating. Several of the most probative references are pre-AIA § 102(e) art — U.S. patents granted on applications filed before the critical date. Their disclosures are available as of their filing dates, so they are combinable under § 103(a) even though they granted later:

Excluded as post-critical-date (appear in the family-citation list but cannot be § 103 art against this priority date): US 7,212,534 (2001-07-23), US 7,245,632 (2001-08-10), US 7,895,431 (2004), US 7,535,907 (2005). They are useful only as background evidence of the state of the art.

Verification caveat. I retrieved and quoted the disclosures of US 6,798,788, US 6,950,434, US 6,742,045, US 6,141,749 and US 6,928,482 directly (search budget was exhausted before I could pull US 6,226,751, US 7,023,863, and US 6,263,368). For those three I rely on title and assignee only and say so explicitly below.

1. The level of ordinary skill and the invention's own framing

The specification frames the problem itself: security appliances such as firewalls and VPN gateways "tend to act like bottlenecks in the network in terms of throughput." The solution claimed is architectural — split the slow, stateful, first-packet-only control work from the fast per-packet data work, across physically separate boards, and let a switching board route between them by inspecting whether a packet is the first in a session.

Critically, nearly every functional element the '716 claims was already in the art for exactly the same reason — wire-rate packet classification and policy application without blocking. That framing matters because the claimed contribution reduces to where the known functions are placed, not what the functions do. Under KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), that is the classic obviousness posture.

2. Claim 1 — the primary combination

Proposed combination:
US 6,798,788 B1 (Viswanath/Kanuri, AMD) + US 6,950,434 B1 (Viswanath/Krishna, AMD) + US 6,141,749 (Coss et al., Lucent) + US 6,928,482 B1 (Ben Nun et al., Cisco).
Optionally supplemented by the Cisco forwarding-agent family (US 6,549,516 / 6,650,641 / 6,633,560) for the distributed service-manager/forwarding-agent split.

Element mapping

Motivation to combine — and it is unusually strong here

1. Same field, same problem, same stated goal. AMD '788 and '434 both state the need to "provide layer 2 switching and layer 3 switching capabilities for 100 Mbps and gigabit links without blocking of the data packets" and "to perform layer 3 processing in real time… while operating at the wire rate." Cisco '482 states the same objective verbatim in result terms: without load balancing, "the overall efficiency of the network component is degraded, and the data and/or applications… cannot be processed in real time or at wire speed." Lucent '749 states its purpose as "increased processing efficiency." The '716 states the identical motivation. Four references converging on the same known problem is the paradigm of KSR's "design incentive."

2. Explicit suggestion in Cisco '482. Its background criticizes prior systems that "do not suggest balancing the processing load of processors within a network component by designating particular processors to handle certain process flows of data packets." That sentence is effectively a roadmap: put the load-balancing/flow-assignment function inside the network component and assign entire flows (sessions) to individual processors. That is claim 1's management-board-assigns-a-session-to-a-processing-board architecture.

3. The first-packet/session split is not merely suggested — it is disclosed for the same purpose. Lucent '749's whole point is that applying a full rule set to every packet is wasteful, so it applies it once (first packet) and caches (subsequent packets). Combining that with a physical control-board/data-board split is the predictable next step once Cisco '482 supplies the multi-processor hardware.

4. Predictable results, no new function. KSR: "the combination of familiar elements according to known methods is likely to be obvious when it does no more than yield predictable results." Every element of claim 1 performs exactly its known function — a port receives, a classifier classifies, a policy engine examines, processors process — and the asserted benefit (higher throughput) is the ordinary consequence of parallelizing known processing across known parallel processors.

5. "Finite number of identified, predictable solutions." Once you have (i) per-flow classification (AMD), (ii) first-packet/remainder session splitting (Lucent), and (iii) parallel packet processors with flow-to-processor assignment (Cisco), there is a small and foreseeable set of ways to arrange them on boards. Selecting the arrangement the '716 discloses is not an inventive leap.

3. Claims 16, 17 and 19

Claim 16 (firewall device): Same combination as claim 1, plus "perform a firewall check on the received data packet." Lucent '749 is a firewall — its rule-processing/caching engine performs exactly the firewall check the claim recites, and its cached-session mechanism is what makes the subsequent packets bypass it. US 6,154,775 (Lucent, dynamic rule processing) adds administrator-loadable/dynamically-alterable rules, reinforcing claim 16 and dependent claim 12.

Claim 17 (secure gateway, firewall + VPN): Add US 6,226,751 (VPNet, "Method and apparatus for configuring a virtual private network") and US 7,023,863 (3Com, "Apparatus and method for processing encrypted packets in a computer network device"). I could not retrieve the bodies of these two references and rely on titles/assignee only — treat this leg as the least-verified part of the analysis. On the titles alone, placing VPN encryption/decryption on the same parallel processing path is a predictable marriage of two well-known functions (security filtering + link encryption), each performing its established function.

Claim 19 (method): Mirrors claim 1 exactly in method form, with the additional step of examining the packet only if it is first-in-session. Lucent '749 supplies precisely that: the rule set is applied to the first packet and bypassed for subsequent packets of the same session.

4. Claim 18 — the "kitchen-sink" independent claim

Claim 18 combines: IP-vs-non-IP determination; switching non-IP packets to the management board; firewall/dynamic-port-database/access-policy checks; and forwarding to a processing board "selected based on a user-customizable criterion."

• IP/non-IP routing to a control path — routine in the art (Lucent '749's firewall operates on IP packets; non-IP handling such as ARP is standard).
• Dynamic port database check — Lucent '749's "dynamic rules… added to a set of access rules for processing packets… a 'one-time' rule which is only used for a single session, a time-limited rule… and a threshold rule." US 6,154,775 elaborates the same dynamic-rule concept. This is the closest art I located to the FTP-POR dynamic-session capture described in the '716.
• User-customizable selection criterion — Cisco '482 expressly contemplates non-uniform assignment: "loads of the processors PP1 to PPN have a certain ratio with respect to each other… or… do not exceed particular thresholds respectively assigned to the processors," and its claims recite selection "based on which of said packet processors has a processing load value corresponding to a lowest processing load category." A user setting the criterion is a design choice.

⚠️ Flag carried forward from the prior section. The retrieved claim text's "or if the data packet is an IP packets" alternative in claim 18 is internally inconsistent with dependent claim 3 (non-IP → management board). If that text is accurate, claim 18 additionally carries a § 112 written-description/enablement vulnerability independent of § 103, and its broadest literal reading would be easier to invalidate. If it is an OCR artifact, ignore. I have not auto-corrected it.

5. Dependent-claim chart (secondary references)

Claim 15 in particular is a list of individually known, separately assignable functions. Under KSR, reciting a menu of known network-security functions — each performing its own known job — does not create patentability in the aggregate.

6. Anticipated counter-arguments and how they fare

A. "Lucent '749 keeps everything inside one firewall processor; the '716 physically separates control and data planes onto different boards."
This is the strongest non-obviousness argument, but it is met by Cisco '482, which physically distributes processing to multiple packet processors with a separate controller that receives the first packet, and by the Cisco forwarding-agent family, which physically separates a service manager from forwarding agents ("forwarding agents may be implemented on routers that already exist at strategic points… the service managers need not be connected to servers"). Once both a distributed control/data split and a first-packet/session split independently exist in the art, placing them on separate boards is arrangement, not invention. KSR explicitly rejects the notion that "a patent composed of several elements is not proved obvious merely by demonstrating that each of its elements was, independently, known in the prior art."

B. Teaching away. I found none in the retrieved text. Cisco '482's discussion of the '425 patent criticizes a sequential ring-passing scheme as impractical — that is a criticism of a specific prior approach (sequential node-by-node load checks), not of load-based flow assignment generally. It affirmatively teaches toward centralized load-based selection, which is what the '716's management board does.

C. Secondary considerations. I found no evidence of record of unexpected results, industry skepticism, or failure of others having a nexus to these claims. Commercial success of the NetScreen/Juniper product line is plausible but, absent established nexus to the claimed arrangement (as opposed to the product's many other features), carries little weight under In re GPAC. A nexus would need to be proven, and it typically is not.

D. Prosecution history. The examiner of record cited only US 6,798,788 and US 6,950,434 — both assigned to AMD and directed to switch-port fragment/policy handling. Neither reference teaches or suggests the board-level first-packet vs. non-first-packet routing split. That explains why the claims issued. But it also means the strongest art (Lucent '749's session-caching firewall; Cisco '482's first-flow controller + parallel packet processors) was apparently not before the examiner, which weakens any argument that issuance itself evidences non-obviousness.

7. Bottom line

Under the US 7,095,716 grant text and the references cited on that page, claims 1, 16, 17, 18 and 19 would very likely have been held obvious under § 103(a) over a combination of:

• US 6,798,788 and US 6,950,434 (AMD) for wire-rate L3/L4 classification, policy lookup, and the fragment/session-caching tables (claims 1–6);
• US 6,141,749 (Lucent) for the firewall rule-processing-and-caching engine that inherently distinguishes a first packet of a session from subsequent packets and performs the firewall/access-policy checks (claims 1, 7, 16, 19);
• US 6,928,482 (Cisco) for the controller-plus-parallel-packet-processors architecture, first-flow determination, and load-based processor selection (claims 1, 8, 9, 14, 18);
• US 6,742,045 (Cisco) and the Cisco forwarding-agent family (US 6,549,516; 6,650,641; 6,633,560; 6,606,315; 6,704,278) for the distributed service-manager/forwarding-agent split, fragment handling, NAT, and stateful failover (claims 6, 15);
• US 6,154,775 and the Lucent dynamic-rule work for user-configurable/dynamic checks (claims 7, 12) — with US 6,226,751 and US 7,023,863 supplying the VPN element (claims 15, 17) at lower confidence, since I verified only their titles.

The motivation is supplied both expressly (each reference states the same wire-rate/non-blocking objective; Cisco '482's background is nearly a roadmap) and by KSR's common-sense/design-incentive principles (same field, known functions, predictable results, finite identified solutions, strong market pressure on security-appliance throughput).

Explicit uncertainty: (1) the VPN-specific references (US 6,226,751, US 7,023,863) and Sun's US 6,263,368 were not retrieved in full, so any assertion about their disclosures rests on titles/assignees alone; (2) the one-day bibliographic discrepancies and the claim-text anomalies flagged in the prior section remain uncorrected and should be resolved against the USPTO official copy before this analysis is used in any formal proceeding.