US 11233777

I'll search for this specific patent number and any litigation activity.

Let me get the actual claim text and check for litigation specifically naming this patent.

US Patent 11,233,777 — Analyst Summary

Important caveat up front: I was able to retrieve the full specification, drawings list, abstract, and bibliographic/legal-status data for US 11,233,777 from the authoritative patent text, but I was not able to retrieve the verbatim claim set (the full-text version I have ends before the claims), and my searches for the exact claim language and for any 2026 CAFC docket specifically naming US 11,233,777 were cut off before returning results. The claim overview below is therefore derived from the specification, the FIG. 1 flowchart, and statements of scope in the description, not quoted from the claims. Treat it as a reconstructed functional summary, not as claim construction.

1. Bibliographic data (from authoritative patent text)

Family note (not auto-corrected): The European counterpart identified is EP 4084402 "Efficient SSL/TLS proxy", filing date 24/07/2018, grant date 06/03/2024, owner listed as Centripetal Limited (Galway, Ireland), and status shown as Lapsed as of 24/07/2024. A later US continuation in the same family is US 12,034,710 (also titled "Efficient SSL/TLS proxy," issued 2024), which recites related subject matter such as "wherein the domain name criteria comprises a host name value extracted from the second list."

2. Abstract (verbatim)

"Systems, devices, and methods are disclosed for selectively decrypting SSL/TLS communications. Contents of the decrypted communications that may result in some action; for example, to terminate the communications, or to log and store the plaintext packets of the communications for subsequent content inspection and analysis. A SSL/TLS proxy may examine the information contained in the TLS handshake protocol and/or examine other information associated with the connection. Based on the examination, a proxy may determine whether or not to decrypt the encrypted communications. The proxy may take additional actions based on content inspection."

3. Plain-language overview of the independent claims (reconstructed from the disclosure)

The specification and FIG. 1 describe three statutory classes of coverage, which is the typical structure for this family (a method, a system/device, and a non-transitory computer-readable medium). A representative set would read as follows:

Independent claim 1 — Method of selectively decrypting TLS-secured communications (per FIG. 1):
A computing device (the "efficient SSL/TLS proxy," or E-PROXY) performs:

1. Constructing two lists of identification data — a first list of URIs ("URI‑decrypt‑list") whose sessions are to be decrypted, and a second list of domain names / host FQDNs ("domain‑name‑decrypt‑list") whose sessions are to be decrypted.
2. Deriving the second list from the first — for each URI in the URI list, extracting the host-name value (FQDN or IP address) from the URI and adding it to the domain-name list; optionally de-duplicating.
3. Inspecting the TLS handshake in the clear — during each TLS handshake (ClientHello → Certificate), extracting the Server Name Indication (SNI) value from ClientHello and the certificate Subject:CN value from the server Certificate. The description states CN is the reliable server FQDN and is preferred when SNI and CN disagree; mismatches may be alerted and/or the session terminated.
4. Comparing the server FQDN against the domain-name list —
   • No match ⇒ do not decrypt; forward packets directly through the TCP agents, bypassing the TLS/proxy function ("Step 1‑5a").
   • Match ⇒ set up and use the proxy function to decrypt and inspect plaintext ("Step 1‑5b").
5. Second-stage URI check after decryption — if the session's domain name entered the list because it was extracted from the URI list, compare the decrypted session's actual URI against the URI list:
   • No URI match ⇒ re-encrypt and forward without applying intermediating logic ("Step 1‑6a").
   • URI match (or the domain was added independently of the URI list) ⇒ apply intermediating logic to the plaintext ("Step 1‑6b"), e.g., block, log/capture plaintext, or transform; then re-encrypt and forward if not blocked.

The stated point of the invention is efficiency: the proxy avoids decrypting the large majority of TLS sessions that no policy cares about, and can also stop passing plaintext through the man-in-the-middle once the URI check fails.

Independent system/apparatus claim: A proxy device comprising, as in FIG. 3: one or more TCP agents (121/122) that terminate TCP connections, maintain flow state, compute flow identifiers, and spoof IP endpoints; one or more TLS agents (123/124) that terminate TLS tunnels, spoof TLS clients/servers, and interact with a certificate authority (126) to mint spoofed X.509 certificates; a MITM intermediary (125) that makes and signals intra-proxy packet-routing decisions and implements higher-level applications; a list manager (128) that builds/maintains the identification lists; memory (129); network interfaces (127); and a data bus (140). The routing logic is the claimed novelty: the MITM signals the TCP/TLS agents to route a given flow's packets either directly between agents (bypass, no decryption) or via the TLS agents and MITM (decrypt and inspect), based on list comparisons.

Independent non-transitory computer-readable media claim: The same steps as the method claim, expressed as instructions that, when executed by one or more processors, cause a computing device to receive/compare a list of domain names and/or URIs, inspect TLS handshake signaling (SNI and/or certificate CN), and selectively decrypt and route the flow accordingly.

Disclosed variations affecting scope (from the description, likely reflected in dependent claims):

• Use of a "domain-name-do-not-decrypt-list" instead of, or in addition to, the decrypt list, with one list given priority over the other (e.g., cybersecurity list vs. privacy-protection list).
• Use of an "IP-address-decrypt-list" in which the TLS agent extracts source/destination IP addresses from the packet header rather than SNI, and the MITM checks those addresses.
• Applicability beyond HTTPS on TCP/443/IPv4, e.g., other TLS-secured protocols (FTPS), other ports, other transports (UDP, SCTP), and IPv6, and to non-transparent proxies.
• Terminating the session (e.g., sending a TCP RST to the client, the server, or both) when the intermediating logic calls for blocking.

4. Litigation / CAFC 2026 check — what I found and did not find

• No CAFC 2026 docket specifically naming US 11,233,777 was returned by my searches. I cannot confirm either the existence or the absence of a 2026 Federal Circuit appeal captioned on this patent. This is a genuine gap in the record I was able to pull, not a statement that no such docket exists.
• Centripetal Networks is an active litigant in this technology space, and this patent family is part of that activity. Search results surfaced materials from Centripetal Networks, Inc. v. Keysight Technologies, Inc., No. 2:22‑cv‑00002 (E.D. Va.), including a complaint exhibit reproducing an IFW cover page for application 16/039,896 (the parent application, filed 2018‑07‑19, published as US 2019/0028439 A1, 20 claims / 9 drawing sheets). Caution: that cover page belongs to the parent (US 10,284,526), not to the '777 continuation (application 16/356,421, published as US 2020/0304476 A1). Do not attribute the parent's "20 claims" figure to the '777 without verifying.
• Broader Centripetal campaign history (Palo Alto Networks, Fortinet, Keysight, Cisco, and the earlier $2.75B Palo Alto verdict later vacated/remanded) is well documented in the ecosystem, but my searches did not return a document tying US 11,233,777 itself to a docket entry in 2026.

5. Explicit uncertainty statements

1. Claims not verified verbatim. The Section 3 overview is reconstructed from the specification and FIG. 1; I did not retrieve the actual numbered claim text of US 11,233,777. Independent-claim count, exact transition language ("comprising"), and antecedent bases are unverified.
2. Claim count and drawing count unverified for the '777 itself. The "20 Claims, 9 Drawing Sheets" figure I saw is from the parent's file-wrapper cover page.
3. Assignee entity name is history-dependent (Inc. vs. LLC vs. Centripetal Limited for the EP member); the statutory register should be consulted for the current owner of record.
4. Legal status and expiration shown above are as presented by Google Patents, which expressly labels them assumptions: Active, adjusted expiration 2039‑04‑24 (presumably reflecting a PTA/terminal-disclaimer adjustment).
5. No CAFC 2026 activity confirmed. If you need a definitive answer, the Docket Navigator / PACER / CAFC CM‑ECF dockets should be queried directly for "11,233,777."

Recommended primary sources to close these gaps: USPTO PatentCenter for application 16/356,421 (claims, IFW, assignment history), the USPTO Patent Assignment Search for the Inc.→LLC change of name, and CAFC CM-ECF / Docket Navigator for any appeal naming 11,233,777.

I'll research litigation involving US Patent 11233777 using multiple sources.

Let me search more specifically for this patent number in litigation databases.

Bottom line

I found no litigation — district court, ITC, or PTAB — in which US Patent No. 11,233,777 was asserted, challenged, or otherwise at issue. As of today (April 26, 2026), based on the searches I was able to run, the '777 patent appears to have no known litigation history.

I want to be explicit about the limits of this conclusion: I was cut off before I could query the Unified Patents litigation caselist, PACER/RECAP, Lex Machina, or Docket Navigator directly, so my negative finding rests on the searches summarized below rather than on an exhaustive docket sweep.

What I searched and what came back

The high-volume Centripetal cases that dominate the results — Centripetal v. Cisco (E.D. Va. 2:18-cv-00094), Centripetal v. Keysight/Ixia (2:17-cv-00383 E.D. Va., plus ITC complaint), Centripetal v. Palo Alto Networks (2:21-cv-00137 E.D. Va.), and the various IPRs (e.g., IPR2022-00182 on the '856 patent; the Centripetal v. Keysight CAFC appeal 2024-2246, argued March 3, 2026) — involve different patents. None of the patent lists surfaced in those matters includes 11,233,777.

Important distinction: the '777's parent WAS litigated

Do not conflate these. US 11,233,777 is a continuation of US 10,284,526 (per the '777 specification: "a continuation of U.S. Pat. No. 10,284,526, filed Jul. 19, 2018, which is a non-provisional of U.S. Patent Application Ser. No. 62/536,254, filed Jul. 24, 2017").

The '526 patent — a different patent number from the same family/specification — was asserted by Centripetal against Keysight Technologies in the ITC complaint filed April 18, 2022 (asserting the '370, '917, and '526 patents), and in related E.D. Va. district court actions. That litigation concerns US 10,284,526, not US 11,233,777. Per your instruction to interpret identifiers literally, I am not treating the '526 litigation as '777 litigation.

Likely explanation

The '777 issued January 25, 2022 — after the filing of the Cisco (2018), Keysight (2017), and Palo Alto Networks (2021) complaints — so it could not have appeared in those original pleadings. Acquisitions of later-issued continuations into an existing case would have required an amended complaint, and I found no evidence of one naming the '777.

Recommended verification before relying on this

Because a negative result is the hardest to prove, I'd confirm via these sources before treating "no litigation" as final:

1. Unified Patents litigation caselist — https://portal.unifiedpatents.com/litigation/caselist — search the patent number under "Asserted Patents."
2. CourtListener/RECAP (free PACER mirror) — full-text search "11,233,777" (with comma variants "11233777" and "11,233,777 B2").
3. USPTO PTAB — Patent Trial and Appeal Board End-to-End or PTAB Center search for IPR/PGR/CBM filings naming the '777 as the challenged patent.
4. Lex Machina / Docket Navigator (paid) — the same query, since these index complaints, infringement contentions, and ITC Section 337 exhibits.
5. USPTO Patent Center / Global Dossier "Litigation" tab and the assignment record — note the '777's chain of title (Centripetal Networks, Inc. → Centripetal Networks, LLC, 2023-01-24) and pending continuation US 12,034,710 (app. 17/556,318, filed 2021-12-20), which may signal intended future assertion.

If any of those sources surfaces a case, it would most plausibly be a later-filed or amended Centripetal complaint (a new Cisco or Keysight action, or a new defendant) filed after January 2022. I have no evidence of such a case, and I will not speculate one into existence.

I'll start by verifying the structured data against web sources, since the ODP block says no proceedings are indexed.

Let me dig into the specific patent family and any IPRs targeting it.

The key hit is IPR2022-01525, but the CAFC opinion says it targets the '526 patent, not the '777. Let me confirm whether any proceeding names US 11,233,777 itself.

Proceedings overview

Total AIA trial proceedings on file against US 11,233,777: 0. The USPTO ODP structured block returns none, and my independent web sweep surfaced none — no IPR, PGR, or CBM has ever been filed against the '777 patent. Accordingly, the breakdown is: 0 active, 0 claims invalidated in a proceeding on this patent, 0 claims sustained, 0 settled, 0 institution-denied.

Bottom line for a defendant: the '777 is not "hardened" — it is simply untested. Unlike a patent that has survived IPRs, US 11,233,777 has never been through the PTAB at all. That is a materially different posture from its parent: the '777 is a continuation of US 10,284,526 (the '526 patent), and every claim of the '526 (claims 1–20) was held unpatentable in IPR2022-01525 and the Federal Circuit affirmed on 2026-04-02. The '777 shares the '526 specification and priority (2017-07-24), so the prior art that killed the parent is directly available against the child — but no party has yet pulled the trigger. Treat this as an unexploited vulnerability, not a defensive moat.

(No proceeding) — US 11,233,777 has no PTAB record

• Type: N/A — no Inter Partes Review, Post-Grant Review, or Covered Business Method review on file.
• Filed: N/A
• Status: No AIA trial proceeding (per USPTO ODP structured data; corroborated by web search).
• Verification note / caveat: I could not run an exhaustive PTAB E2E party-name query against "11,233,777" within my tool limits. The ODP canonical list is the controlling source here and returns nothing. Before relying on this in litigation, confirm on PTAB E2E and Patent Center for the '777 (Application No. 16/356,421). One apparent hit — a Google Patents "Legal Events" line referencing "TRIAL NO: IPR2022-01525, Opponent name: KEYSIGHT TECHNOLOGIES, INC." appearing alongside both US10284526 and US11233777 in a family view — resolves to the '526 patent, not the '777 (confirmed by the CAFC opinion and PTAB record below). Do not cite it as a proceeding on the '777.
• Defensive value: With no institution decision and no estoppel on the '777, a defendant retains the full statutory window and the full prior-art field for a fresh petition — subject to § 325(d) and General Plastic considerations discussed below.

IPR2022-01525 — Keysight Technologies, Inc. v. Centripetal Networks, LLC

(Family context only — this proceeding is on U.S. Patent 10,284,526, the '777's parent, NOT on US 11,233,777.)

• Type: Inter Partes Review
• Filed: 2022-09-12 (Unified Patents docket record)
• Status: Final Written Decision issued; all challenged claims unpatentable; affirmed on appeal.
• Judge panel: The oral-hearing transcript in the record references "Judge McNamara" as a panel member. I could not independently confirm the full three-APJ panel from the sources retrieved — do not attribute the panel without checking the FWD caption (Paper 27).
• Petition grounds: Keysight challenged all claims of the '526 patent (claims 1–20). The Board found claim 1 (representative) unpatentable on four alternative grounds:
  1. Anticipated by Cisco IronPort AsyncOS 7.1 for Web User Guide ("IPUG") — § 102;
  2. Anticipated by U.S. Patent Application 2012/0290829 ("Altman") — § 102;
  3. Obvious over IPUG — § 103;
  4. Obvious over Altman in combination with U.S. Patent Application 2015/0121449 ("CP") — § 103.
• Institution decision: Instituted (J.A. 267–330). Exact institution date not confirmed from my sources; the petition was filed 2022-09-12, so institution fell in the ordinary ~6-month window.
• Final Written Decision: 2024-04-15, Paper 27, 68 pages — claims 1–20 unpatentable. The Board's key construction: the claim-1 limitation "corresponding action" includes any action, including the action of allowing a further transmission of a packet, without any further action. Quoting the panel's reasoning as recounted on appeal: "'allowing' a packet is the opposite of 'blocking' it and would naturally be considered an action." The Board also found IPUG was a printed publication under § 102.
• Settlement / termination: None. The case ran to a merits FWD and through appeal.
• Appeal: Yes — affirmed. Centripetal Networks, LLC v. Keysight Technologies, Inc., No. 24-2246 (Fed. Cir. 2026-04-02), nonprecedential, Judge Lourie writing. The court affirmed on the IPUG-anticipation ground and deemed the other three grounds moot. It rejected Centripetal's arguments that (a) the "corresponding action" construction rendered the "transmitting...to its intended destination" limitation superfluous, and (b) IPUG was not a publicly accessible printed publication. Opinion: https://www.cafc.uscourts.gov/opinions-orders/24-2246.OPINION.4-2-2026_2670414.pdf ; mirror at CourtListener.
• Defensive value (for the family, and for the '777 as a continuation): This is the single most useful piece of ammunition a defendant has. It proves the '526/'777 specification's core selective-decryption claims are patentably indistinguishable from IPUG alone under the Board's and CAFC's construction — and IPUG is a printed publication with an established pre-priority-date accessibility record. Any § 102 IPUG or Altman theory against the '777 starts from an affirmed win, not a hypothesis.

Strategic summary

Canceled vs. sustained vs. untested. On the '777 itself: every claim is untested — no claim has been canceled, and none has been sustained, because no proceeding exists. On the parent '526: claims 1–20 are canceled (FWD 2024-04-15, affirmed 2026-04-02). The '777's claims are the family's live continuation claims and have not been adjudicated anywhere. I have no reliable source for the '777's exact claim set, so I will not name surviving claims — there are none to name from a PTAB record.

Estoppel landscape. § 315(e)(2) estoppel from IPR2022-01525 runs against Keysight and its privies, and only as to the '526 patent — the statute operates patent-by-patent, so it does not bar anyone from petitioning against the '777. Practically:

• A defendant other than Keysight (e.g., Cisco, Palo Alto, a new entrant) faces no statutory estoppel on the '777 and can raise any ground, including IPUG and Altman.
• Keysight would be estopped as to grounds it raised or reasonably could have raised on the '526, but a new IPR on the '777 is a different patent — expect a fight over privity/abuse, but no clean statutory bar.
• Watch the non-statutory gates: § 325(d) (IPUG/Altman are now in the '526 prosecution/IPR record — a petitioner should expect the Board to weigh whether the art was "previously presented"), and General Plastic if a serial petitioner files after an earlier loss on a sibling.
• Still-available grounds: any art not in the IPR2022-01525 record (including new § 102/§ 103 combinations and, if the claims were ever narrowed, § 112 written-description attacks — note that in the Cisco line the Board itself raised a sua sponte written-description issue, which Centripetal litigated all the way up).

Pattern signals. Same-petitioner aggregation: Keysight has been the family's most persistent PTAB challenger (IPR2022-01525 on the '526; other IPRs on the '917 and '370), while Cisco challenged the '856 and '193 and Palo Alto the '343 — a three-front campaign across the portfolio, but none of them has touched the '777. Patent owner posture: Centripetal litigates hard and appeals aggressively — it took IPR2022-01525 to the Federal Circuit and has filed repeated SCOTUS cert petitions in the Cisco line, and it ran the ITC case (Inv. No. 337-TA-1314) to a no-violation Commission ruling. No defensive aggregator (e.g., Unified Patents) appears anywhere in the chain for this family; the challengers are all operating-company defendants. Finally, the '777 appears never to have been asserted in any of the district-court or ITC actions I reviewed (those asserted the '370, '806, '193, '856, '176, '205, '917, '343, and '526) — consistent with it being a continuation held in reserve.

Recommended next steps

1. Confirm the zero-count on PTAB E2E. Search party "Centripetal" and patent number 11,233,777 in PTAB E2E and check the '777's Patent Center transaction history (App. 16/356,421). My tool sweep and the ODP block agree, but confirm before you rely on it.
2. Weaponize the parent's loss. If you are a defendant and Centripetal asserts the '777, immediately build your invalidity story on IPUG and Altman using the affirmed constructions from IPR2022-01525 — quote the FWD at Paper 27 (2024-04-15) and the CAFC disposition in No. 24-2246 (2026-04-02) for the proposition that "corresponding action" covers merely allowing a packet to proceed. That construction is the family's achilles heel.
3. Evaluate your own IPR on the '777 now. With no estoppel and an affirmed printed-publication record for IPUG, a petition against the '777 is unusually well-positioned. Budget for a § 325(d) fight and cite the '526 FWD only as persuasive/supporting, since the '777's claims may recite differently.
4. No pending milestones to track. Because there is no active proceeding on the '777, there are no institution-deadline, oral-hearing, or statutory 1-year FWD dates to diary. Instead, diary the § 315(b) one-year bar from service of any complaint asserting the '777, and the § 315(a)(1) bar if you file a DJ action first.
5. Watch the family's other appeals. The '917 and '370 ITC appeals (Centripetal Networks, LLC v. Int'l Trade Comm'n, Nos. 24-1416 and companion 24-1406, Fed. Cir. Apr. 2026) show the CAFC's current disposition toward Centripetal's claims — useful predictive signal for how a '777 appeal would fare, even though neither is a proceeding on this patent.

Sources for every specific citation above: the CAFC opinion at the link provided, the Fed. Cir. Blog and IPWatchdog accounts of the 2026-04-02 decision, and the Unified Patents / Google Patents family records. I did not fabricate any proceeding number, date, or panel composition; where a fact was unconfirmed (institution date, full panel), I said so.

I'll research the assignment record and litigation history before assembling the report.

Let me dig for the specific assignment reel/frame records and the corporate history.

Significant leads. Let me verify the ownership transfer to Centripetal Limited, current corporate status, and any assertion of the '777 patent.

Assignment & Ownership Analysis — US 11,233,777 B2

Patent: US 11,233,777 B2 — "Efficient SSL/TLS proxy"
Application: US 16/356,421, filed 2019-03-18 (continuation of US 16/039,896, filed 2018-07-19, which issued as US 10,284,526; non-provisional of provisional 62/536,254, filed 2017-07-24)
Issued: 2022-01-25 · Adjusted expiration: 2039-04-24 · Status: Active

Sourcing note (read first). I retrieved the Google Patents legal-events record for US 11,233,777 (https://patents.google.com/patent/[US11233777B2](/patent/US11233777B2)/en), which is derived from USPTO assignment data, plus corroborating court/agency filings. The reel/frame numbers for the two post-issuance records were not exposed in the index I retrieved, and I will not invent them. Where I say "reel/frame not retrieved," treat that as an open verification item for https://assignmentcenter.uspto.gov/ (patent number search for 11233777). Everything else below is grounded in a named source.

Inventors

• Only one inventor is named. This eliminates the classic "all inventors departed within 12 months" fire-sale precursor — there is no inventor team to disperse.
• Moore is the sole named inventor on the entire "Efficient SSL/TLS proxy" family (the parent '526, the '777, EP 4 084 402, and the 2024 continuation US 2025/0141854 A1), which is consistent with a founder-level / key-employee inventor rather than a rank-and-file engineer. (I did not find a verified source stating his exact title, so I flag his precise role as not independently confirmed.)
• Unusual pattern observed: the inventor's assignment to the company was recorded 2021-05-26 — roughly two years after the 2019-03-18 filing and only ~8 months before issuance. That latency is more consistent with a confirmatory/corrective recordation (or a late-filed employment assignment) than with a contemporaneous filing-date assignment. It is not evidence of a transfer away from the company.

Original assignee

Centripetal Networks, Inc., a Delaware corporation (formed 2009-02-25).

• Caveat on naming: Google Patents lists "Centripetal Networks LLC" as original assignee. That is retroactive labeling — the conversion to an LLC was not effective until 2022-12-30, i.e., after the 2022-01-25 issuance. The as-issued assignee was Centripetal Networks, Inc.
• Primary line of business: inline network-security appliances and threat-intelligence enforcement for enterprise/government networks — the RuleGATE gateway line and the CleanINTERNET managed service. It is a genuine operating company, not a licensing vehicle.
• Did they ship a product embodying the claims? Substantially yes for the parent claim set. In the ITC Section 337 investigation, Centripetal submitted claim charts and a corporate declaration stating that its Domestic Industry Products practice claim 1 of the '526 patent — the direct parent of the '777 — including storing a list of identification data with a corresponding action, filtering encrypted traffic against it, decrypting on a match, and re-encrypting (ITC domestic-industry submission, Ex. 66C and ¶98, filed in the Keysight ITC matter). The Commission ultimately found the technical prong not met for a different patent ('370) and no Section 337 violation; that finding is patent-specific and does not erase the RuleGATE/CleanINTERNET product line.
• Current status: Operating. Converted by Certificate of Conversion from Centripetal Networks, Inc. to Centripetal Networks, LLC, effective 2022-12-30 (certificate executed 2022-10-17; Delaware registered office = The Corporation Trust Company, 1209 Orange Street, Wilmington, DE 19801). It states in filings that it remains the same entity by operation of law. Federal award records also show a CNI Holdings, Inc. d/b/a Centripetal Networks, LLC at 1875 Explorer St., Suite 900, Reston, VA (holding-company NAICS 551112) — i.e., a parent-holding structure was layered in around 2022-02-22, contemporaneously with the conversion. As of 2026 it is still litigating (SCOTUS cert petition filed 2026-09).

Assignment timeline

Two post-issuance records appear in the indexed legal-events data. No third-party or NPE transfer exists in the US chain.

1. ~2019 (executed, exact date not retrieved) / recorded 2021-05-26 — Reel/frame not retrieved

• Conveyance: Assignment of assignors' interest (inventor→company)
• Assignor: Moore, Sean (sole inventor)
• Assignee: Centripetal Networks, Inc.
• Correspondent: Not retrieved from the index. For context, the family's prosecuting firm of record on the patent face as reproduced in E.D. Va. pleadings is Banner & Witcoff, Ltd. (large general-practice IP firm; no NPE-asserter reputation found). Prosecuting counsel ≠ recording correspondent, so I am not treating this as a repeat-correspondent finding.
• Context: Internal capture of founder/employee invention rights — routine, not an acquisition or fire-sale.

2. 2022-10-17 (conversion executed) / conversion effective 2022-12-30 / recorded 2023-01-24 — Reel/frame not retrieved

• Conveyance: Change of Name (corporate conversion, Corp.→LLC)
• Assignor: Centripetal Networks, Inc.
• Assignee: Centripetal Networks, LLC
• Correspondent: Not retrieved. The recordation was foreshadowed in the PTAB filing Patent Owner: Modification of Notice of Real Party in Interest, IPR2022-00182 (Jan. 19, 2023), which states the name changed Dec. 30, 2022 and that "Patent Owner will be filing a recordation of the name change for the patent at the USPTO shortly" — the 2023-01-24 recordation matches that statement.
• Context: Change of name only — Delaware §266/§18-214 conversion; same entity, no change in beneficial ownership. Under Delaware law all property and causes of action remain vested in the converted LLC.

Adjacent items that are NOT US assignment records for this patent, but matter to the ownership picture:

• Security interest (unclear whether it reaches the '777): As of 2017-04-17, Centripetal Networks, Inc. granted Douglas A. Smith a first-priority security interest in its patents and trademarks under a Note and Warrant Purchase Agreement (USPTO/EPAS submission ID PAT4374169, 14 properties listed, including US 8,492,725 and US 9,565,213). The '777 did not exist in 2017, but the grant covers "all patents issued or assigned to, and all patent applications … made by" the Grantor "whether presently existing or hereafter acquired." I found no recorded release. If still unreleased, a third party holds a security interest in the family. This is an encumbrance, not a conveyance of title. Flag as unclear.
• EP-family transfer to an Irish affiliate (counterpart, not the US patent): A contract dated 2023-01-27 transferred European family rights from Centripetal Networks, LLC (Delaware) to Centripetal Limited (Galway Technology Centre, Mervue Business Park, Galway, Ireland). This is documented on the Irish and Luxembourg registers for EP 4 084 402 — same title, same inventor (Moore), same priority (62/536,254 / 16/039,896) — where "Current Proprietor: Centripetal Limited" appears from 2024-02-28. The transfer was attacked by Cisco in French proceedings (Cour de cassation / Paris Court of Appeal records), where Cisco argued the Centripetal group is "un empilement de multiples sociétés" and pointed to a separate BVI entity, Centripetal VI LLC, sharing the "Centripetal Networks, LLC" name. I could not confirm whether the US '777 was included in a parallel US recordation to Centripetal Limited. This is the single most important open item for a full chain reconstruction.
• Continuation activity continuing through 2024: US 17/556,318 → US 12,034,710 (granted 2024-07-09) and US 18/733,063 (published as US 2025/0141854 A1, filed 2024-06-04), both still naming Centripetal Networks, LLC. Active family prosecution is inconsistent with a patent being parked or dumped.

Timeline diagram

timeline
    title Ownership of US 11233777
    2017 : Provisional application filed
         : Patent security interest granted
    2018 : Parent application filed
    2019 : Continuation application filed
    2021 : Inventor assignment recorded
    2022 : Patent issued
         : Delaware conversion to LLC
    2023 : Change of name recorded
         : EP family assigned to Centripetal Limited
    2024 : Continuation filings remain with LLC

NPE / troll-pattern signals

1. Shell-entity transfer — not present (US chain); unclear (group level). The only US transfer is a §266 conversion, which by Delaware statute (6 Del. C. §18-214) leaves title vested in the same entity. The new LLC's Delaware address is a Corporation Trust Company registered-agent address (1209 Orange Street, Wilmington) — but that is the default registered office for a large fraction of all Delaware entities and is not, standing alone, an NPE tell, so I do not score it. The layered holding company (CNI Holdings, Inc. d/b/a Centripetal Networks, LLC, NAICS 551112) and the Irish/BVI "Centripetal" entities are the only structure that warrants a second look, and I could not tie them to a US recordation for the '777.

2. Known asserter in the chain — not present. No assignee in the chain (Centripetal Networks, Inc. / LLC / CNI Holdings) appears on any of the named NPE lists (Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Conversant/Mosaid, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation, Spangenberg entities). Centripetal appears in litigation databases as a plaintiff, but as an operating vendor, not as a monetization vehicle.

3. Repeat correspondent across the chain — not retrievable / cannot substantiate. The two recordations' correspondents of record were not exposed in the data I could reach, so I make no finding. For completeness: the patent family's prosecuting firm of record is Banner & Witcoff, Ltd. (per the patent face reproduced in Centripetal Networks, Inc. v. Keysight Technologies, Inc., No. 2:22-cv-00002, E.D. Va.) — a large, mixed NPE/operating-company practice, and a single appearance on a prosecution face is not a repeat-correspondent signal. Verify correspondent names across both reel/frame entries directly in Assignment Center.

4. Cascading transfers (<24 mo through chained LLCs) — not present. Zero transfers to third parties in the US chain; the 2022 conversion and the 2023 name-change recordation are one event, not a chain.

5. Pre-litigation transfer — not present. The change-of-name recordation (2023-01-24) postdates every assertion by years (Keysight E.D. Va. filed 2017 and 2022; Cisco 2018; Palo Alto 2021). Nothing in the chain was timed to a complaint. Separately, I could not confirm that US 11,233,777 has ever been asserted — the family members I can document in suits are the parent '526 (asserted against Keysight and Palo Alto; claims 1–20 held unpatentable in IPR2022-01525, affirmed Fed. Cir. 2026-04-02) and the '370/'917 patents in the ITC action.

6. Bankruptcy fire-sale — not present. No Chapter 7/11 filing by Centripetal Networks found in any source reviewed (court dockets, SEC-adjacent filings, ITC/Federal Circuit records through 2026). The company is actively litigating and repaying cost awards — inconsistent with insolvency.

7. Privateering — not present. There is no operating-company→NPE transfer. Centripetal asserts its own patents against its own competitors (Cisco, Keysight/Ixia, Palo Alto Networks) while selling RuleGATE/CleanINTERNET. Notably, the inverse of privateering is documented: Cisco and Centripetal had a 2016 NDA and a strategic-investment/joint-selling exploration, and the district court found Cisco copied the technology after those meetings (E.D. Va. opinion; reexamination testimony of Centripetal's corporate representative).

8. Defensive aggregator — not present. The chain terminates at an operating vendor, not at RPX, AST, LOT, Unified Patents, or OIN. No evidence this patent has been neutralized by defensive aggregation.

Verdict

Operating-company assertion.

The US assignment chain is two entries long and entirely internal: an inventor→company assignment from Sean Moore to Centripetal Networks, Inc. (recorded 2021-05-26) and a Change of Name to Centripetal Networks, LLC (conversion effective 2022-12-30, recorded 2023-01-24) — the latter vesting no title change by operation of 6 Del. C. §18-214. Centripetal is a real Reston, VA network-security vendor that sells the RuleGATE/CleanINTERNET products practicing the parent claim set and operates ~80 employees in the US, and it has asserted the family against actual competitors (Cisco, Keysight, Palo Alto Networks) in district court, the ITC, and the UPC. No NPE signal is present on the US record. Two caveats keep this from being a clean bill: (i) an unresolved 2017 security interest to Douglas A. Smith (EPAS PAT4374169) whose collateral clause may sweep in later-issued patents including the '777, and (ii) the parallel EP-family transfer (2023-01-27) to Centripetal Limited (Ireland), with Cisco disputing the group's entity structure and a same-named BVI entity. Neither is an NPE transfer, but both should be resolved before treating title as unencumbered.

Verify at: https://assignmentcenter.uspto.gov/ (search patent 11233777) — pull reel/frame and correspondent for both entries above; and https://patents.google.com/patent/US11233777B2/en for the legal-events view.

I'll search for the specific patent and its cited references. Let me run several targeted queries.

Let me dig into the specific "References Cited" section for this patent, including its parent's front page.

The Justia page appears to contain the actual "References Cited" list. Let me pull more of it.

1. Scope, method, and what I could verify

I searched for the identifier exactly as given — 11233777 / US 11,233,777 — and did not accept results for adjacent numbers. The identifier resolves to a single, unambiguous document:

Two threshold findings you need before reading the prior‑art analysis:

(a) The "References Cited" on the face of the '777 is a family‑wide IDS file, not a hand‑picked prior‑art set. The citation list on Justia's page for 11233777 (https://patents.justia.com/patent/11233777) and the Google Patents "Family Cites Families" table (https://patents.google.com/patent/US11233777B2/en) contain hundreds of entries — the character of the list is packet‑filtering/firewall and policy‑lookup art (e.g., US 6,226,372 Beebe; US 6,279,113 Vaidya; US 6,317,837 Kenworthy; US 6,484,261 Wiegel; US 8,031,517 / 8,042,167 Fulp; and Centripetal's own earlier US 9,094,445, 9,124,552, 9,137,205, 9,160,713, 9,686,193), plus an equally large NPL block (trie minimization, firewall policy advisors, RFC 2474/2475 DiffServ, etc.). That is because the '777's IDS inherits the reference lists of Centripetal's earlier patents and of its IPR‑related file histories. The identical list appears in the child US 12,034,710 (https://patents.justia.com/patent/[12034710](/patent/12034710)) — confirming it is inherited, not '777‑specific. Treating every one of those as "prior art relevant to selective TLS decryption" would be a category error.

(b) I could not retrieve the '777's own verbatim claim set, so the "claims potentially anticipated" column below is mapped to (i) the reconstructed independent‑claim features from the previously generated sections, and (ii) one verbatim claim I did recover — the parent's claim 1, as reproduced in an ITC/PTAB filing:

"1. A method comprising: storing, by a computing device, a list of identification data and at least one corresponding action to perform on encrypted communication flows associated with corresponding identification data; receiving … one or more packets initiating at least one encrypted communication flow; identifying … flow identification data associated with the one or more packets …; comparing … the identified flow identification data with the list …; and decrypting … based on the comparing resulting in a match …, each packet of an encrypted communication flow associated with the match … and performing a corresponding action …; and re‑encrypting, after performing the corresponding action, each packet … and transmitting each packet … to its intended destination."
(Source: https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1549775](/patent/1549775)/… — '526 Patent, claims 1/11/3/13/16 as reproduced in the ITC matter.)

Contradiction flag: this verbatim '526 claim 1 describes the invention as "selectively decrypting" via a stored identification list plus a corresponding action — i.e., the "corresponding action" is performed on the decrypted packets. The earlier generated Summary/Claim‑overview section reconstructed the independent claim around SNI → domain‑name‑list → decrypt → URI‑list → intermediating logic as the core. The two are consistent at the level of substance, but the reconstructed version (from FIG. 1) is narrower/different in sequence than the actual granted '526 claim 1. Whoever consumes this should not treat the reconstructed claim as claim construction for the '777.

2. The most relevant cited prior art — citation, dates, description, provisional § 102 mapping

Prioritized by subject‑matter relevance to the '777, not by whether the Examiner applied it. "Anticipation" requires one reference disclosing every element of a claim; where a reference only supplies some elements, I say so.

A. Directly on point — SSL/TLS interception and selective/conditional handling

A1. "Examining SSL‑encrypted Communications: Netronome SSL Inspector™ Solution Overview." Jan. 1, 2008 (NPL; appears in the family NPL block with an XP number; also confirmed in an IDS filed Jan. 15, 2019 per the '526 IPR petition record).

• Description: vendor solution overview for an inline/transparent appliance that decrypts SSL‑encrypted traffic so it can be inspected — i.e., exactly the proxy/MITM architecture and "decrypt‑then‑inspect" step of the '777.
• § 102 mapping (provisional): Potential § 102 basis for the decrypt/inspect/re‑encrypt steps and for the apparatus claim's TLS‑agent + MITM architecture — only if the reference also discloses selective decryption driven by a stored identification list and a compare step. If it discloses unconditional decryption, it is § 102 art against species claims but not against the list‑driven independent claims; it then becomes § 103 art combined with the list/policy art in group B.

A2. US 2003/0088787 A1 (Egevang), published May 8, 2003. Listed on the '777 face (Justia: "20030088787 | May 8, 2003 | Egevang").

• Note on the identifier: the PTAB/ITC record spells the name "Evevang" in one place and Justia lists it as "Egevang." I am not auto‑correcting either; the reference number US 2003/0088787 A1 is what matters.
• Significance: the prosecution record reports the Examiner rejected application claims 1–6, 8–16 and 18–20 as anticipated by U.S. 2003/0088787 (Evevang) for this family (source: PTAB petition document, https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1550287](/patent/1550287)/…, referring to a 10/12/2018 non‑final Office Action). This makes A2 the single most likely § 102 reference of record. Caveat: the snippet ties that rejection to the '526/family file history; I could not verify the reference's disclosure content directly, and I flag that the rejection may belong to the '526 rather than the '777's own file.

A3. US 2006/0137009 A1 (Chesla), June 22, 2006. Listed on the '777 face.

• Description: network‑security/encrypted‑traffic handling (Chesla is associated with SSL‑interception appliance work). Content not independently verified here.
• § 102 mapping: candidate against claims reciting interception of an encrypted flow and inspection of its content; verify before relying.

A4. US 2006/0133377 A1 (Jain), June 22, 2006. Listed on the '777 face (and independently surfaced in an EPO search report as "US 2006133777 A1," 22‑06‑2006).

• Description/content: not verified in this pass. § 102 mapping: none assigned — flag for verification.

A5. US 7,610,621 B2 (Turley et al.), Oct. 27, 2009 — secure remote access / SSL VPN client architecture; A6. US 7,143,438 B2 (Coss et al.), Nov. 28, 2006; A7. US 7,299,353 B2 (Le Pennec et al.), Nov. 20, 2007; A8. US 2005/0114704 A1 (Swander), May 26, 2005 (NAT/secure‑transport traversal).

• These are network‑security/tunneling references from the inherited IDS. Descriptions flagged unverified. Their § 102 exposure is limited to secondary claim elements (endpoint spoofing, tunnel termination); they are more naturally § 103 art.

B. List‑storage / compare‑and‑act art (the "storing a list of identification data … comparing …" limitation)

These are numerous and mostly inherited from Centripetal's firewall family. Representative entries on the '777 face:

• § 102 mapping (provisional): These support the "storing a list of identification data … comparing … performing a corresponding action" limitation in generalized form. On their own they do not disclose decrypting/re‑encrypting TLS flows, so they are not standalone § 102 anticipation art for the '777's independent claims; they are § 103 combination material with A1/A3.
• Caution: US 9,094,445 / 9,124,552 / 9,137,205 / 9,160,713 / 9,686,193 are Centripetal's own patents. They are citable as § 102(a)(2)/102(e) art only as to their own disclosures, and common‑ownership/§ 102(b)(2)(C) issues attach. Several of the NPL entries in the very same list are the IPR petitions and expert declarations against those Centripetal patents (IPR2018‑01386 on the '213, ‑01436 on the '552, ‑01437 on the '713, ‑01443/‑01444 on the '205, with Kevin Jeffay declarations) — collateral file‑history material, not technical prior art about TLS.

C. Threat‑intelligence / malicious‑domain art (supports "identification data" being domain names from CTI)

• "The Distribution of Malicious Domains," The DomainTools Report, 2016 Edition, Mar. 9, 2016, pp. 1‑11, XP055502306 — listed on the '777 face. Establishes the practice of maintaining domain‑name lists of malicious infrastructure; supports the claim‑3‑type limitation ("receiving … via a subscription service … network addresses and/or domain names … from cyber threat intelligence providers"). Not § 102 art against the decrypt/compare claims.

D. Proxy configuration art

• "Cisco ACNS Software Configuration Guide for Centrally Managed Deployments," Release 5.5, Text Part No. OL‑9136‑01, Cisco Systems, 2006, 944 pp. — listed on the '777 face. Supports a general‑purpose caching/proxy appliance background; § 103 background only.

E. Art that is NOT on the '777's face but is the closest § 102/§ 103 art for this family (from the '526 IPR record)

Because the '777 shares the '526 specification, this art bears directly on the '777's claims even though it appears in IPR rather than on the '777 face:

• "Cisco IronPort AsyncOS 7.1 for Web User Guide" ("IPUG") — Ex. 1008 in the family IPR; describes an HTTPS‑intercepting web security appliance with policy‑driven handling; the IPR asserts it discloses the "typically … decrypts all … SSL/TLS‑secured communications" architecture and policy‑based handling. Prime § 102/§ 103 candidate.
• Altman (U.S. patent/publication; number not verified in this pass) — named primary reference; "Netronome … is incorporated by reference into Altman."
• Jeff Hughes, "Proxy Appliances control Web access," Network World, May 10, 2014 — evidence that HTTPS‑proxying web appliances were prevalent.
• Source anchor: PTAB petition set referencing the '526, https://ptacts.uspto.gov/ptacts/public-informations/petitions/1550287/ and /1549775/.

3. Explicit statements of what I could NOT establish

1. Verbatim '777 claims and the '777‑specific examiner rejections were not retrieved. Therefore the "claims potentially anticipated" mappings above are keyed to (a) the reconstructed claim 1/11/16 features from the earlier sections and (b) the parent's verbatim claim 1. They are not § 102 validity conclusions on the '777.
2. Descriptions marked "not verified"/"flagged" (A4 Jain; A5–A8; several group‑B references) are name/number/date‑only from the citation list. I did not confirm what those documents actually disclose, and I will not invent a disclosure.
3. The "References Cited" list on the '777 face is not a curated prior‑art set. It is an inherited, several‑hundred‑entry IDS. Any "each citation anticipates claim X" exercise run over that list wholesale would be misleading; anticipate‑level relevance concentrates in group A plus the IPR art in group E.
4. The parent US 10,284,526 and its EP/CN/AU siblings (EP 3659316 B1, EP 4084402 B1, CN 111034150, AU 2018307756) are same‑family documents sharing the 2017‑07‑24 effective filing date and are therefore not § 102 prior art against the '777.
5. A single‑reference anticipation of the '777's independent claims is unlikely on this record. The strongest candidates (A1 Netronome, IPUG) disclose decryption‑for‑inspection; the selective, list‑driven decrypt/compare/re‑encrypt combination is where the family survived prosecution. Expect the art to be applied in § 103 combinations (e.g., A1/A3 or IPUG + group‑B list/compare art), with § 102 arguments strongest against the broadest "storing a list / comparing / decrypting on a match / re‑encrypting and forwarding" claims if Egevang (A2) reads as the Examiner reportedly found.

Recommended primary sources to close the gaps: USPTO PatentCenter for application 16/356,421 (full claim set, IFW, the actual Notice of Allowance and any § 102 rejections); the '526 file history (application 16/039,896, including the 10/12/2018 non‑final Office Action citing Egevang) via PTAB/PACER exhibits; and Google Patents/Justia page 4–8 of patents.justia.com/patent/11233777 for the complete front‑page reference list.

I'll try to retrieve the actual prior-art citations for this patent before analyzing, since the "Prior Art" section content wasn't included in the material passed to me.

Good — I now have the parent '526 claims verbatim, the IPR petitions against the family, and key prior art. Let me pin down the '777 claim text and the family's prior-art citations.

Important provenance note before the analysis

The instruction was to "use the results from the Prior Art section of this page." The material actually passed to me contains no prior-art reference list — the fetched patent text included only the bibliographic fields Prior art keywords: list, encrypted communication, packets, flow, tls and Prior art date 2017-07-24, and the full text ends mid-sentence in the description (before the claims). So I could not execute that instruction literally.

Instead, I retrieved the citation record and the family's litigation/PTAB prior-art record by search and built the analysis on those. Everything labeled "retrieved" below came from search results; everything labeled "inferred" is my reasoning. Nothing below is a verbatim quotation of an unretrieved '777 claim.

1. Assumed claim scope (carry-over from the prior section, with caveats)

Because the '777 is a continuation of US 10,284,526 on an identical specification, and because the parent's claims were retrievable, the parent's claim language is strong (but not conclusive) evidence of the '777's scope:

• US 10,284,526 claim 1 (retrieved verbatim): storing a list of identification data and at least one corresponding action; receiving packets initiating an encrypted flow; identifying flow identification data; comparing; decrypting each packet of a matching flow and performing the action; re-encrypting and transmitting to the intended destination.
• '526 claim 7 (retrieved verbatim) — the closest thing I have to the '777's asserted two-list concept: receiving a first list (flows to be decrypted), receiving a second list (flows not to be decrypted), assigning different priorities, and "creating, based on the first priority and the second priority, an ordered list of identification data."
• A later family member, US 12,034,710, is reported to recite "wherein the domain name criteria comprises a host name value extracted from the second list" — i.e., the FIG. 1 Step 1-2 derivation (extract host names from URIs and fold them into the domain-name list).

Working scope for this analysis (assumed, not verified): (i) construct a URI list and a domain-name list, deriving the latter in part from the former; (ii) inspect SNI from ClientHello and/or Subject:CN from the Certificate in the clear; (iii) compare against the domain list — no match ⇒ route around the TLS/proxy function; match ⇒ terminate and decrypt; (iv) post-decryption, compare the URI and, on no match, re-encrypt and forward while bypassing the MITM; (v) a device claim covering TCP agents/TLS agents/MITM/list manager; (vi) an NRCRM claim. Claim count of the '777 itself is unverified — the "20 Claims, 9 Drawing Sheets" figure in the record belongs to the parent.

2. Prior art available on the record (retrieved)

Also retrieved: the '777's own "Family Cites Families" table lists 328 references, and the family's foreign members are EP 3659316 B1, EP 4084402, CN 111034150 A/B, AU 2018307756 A1, AU 2023251475 A1 (i.e., the same disclosure was examined in multiple offices — useful for locating additional art).

3. Element-by-element mapping (assumed claim vs. retrieved art)

The novelty pressure point is narrow: the strongest non‑cumulative feature is the two‑stage cascade — a cheap, plaintext-visible domain test to decide whether to spend the resources to decrypt, followed by a second, URI‑level test on the plaintext to decide whether the plaintext actually needs to traverse the MITM. Notably, the Commission's modified-reasoning finding that Check Point's Application‑and‑URL‑Filter-based approach (category rules → decrypt and inspect) satisfied the '526's "create the list … based on the received … network addresses and/or domain names" limitation shows that adjudicators have already been willing to read a post‑decryption filtering architecture into a pre‑decryption list‑creation limitation.

4. Obviousness grounds under §103

POSITA definition (assumed): a B.S. in CS/EE plus ~2–4 years in network security appliances, or equivalent, familiar with TCP/IP, TLS/SSL handshake message flow, HTTP/HTTPS, and inline security appliances — a level consistent with the declarants of record.

Ground 1 — Buruganahalli '942 alone, or in view of IPUG

'942 discloses the entire core loop: SNI extraction in the clear → certificate‑domain extraction → comparison → policy application → conditional decrypt/not‑decrypt with MITM‑style decryption on the "blacklist." IPUG supplies the missing administrative machinery that the '777's assumed claims recite: a policy table with per‑entry actions and priorities, a bypass list keyed on IP addresses, host names, or domain names, and a global default — which maps onto the '526 claim 7 descendant concept of two lists with different priorities merged into an ordered list. Motivation: both references address the identical problem — applying differentiated handling to encrypted sessions without decrypting everything — and both use the same mechanism (an identity predicate observable in the handshake). A POSITA seeking to operationalize '942's "blacklist" as an enterprise policy would naturally adopt a tabulated policy with explicit actions and precedences, which is exactly the conventional configuration IPUG teaches. Reasonable expectation of success: high — the combination is a policy‑table lookup layered on an already‑disclosed extraction/comparison loop, not a new protocol mechanism.

Ground 2 — US 9,237,168 + IPUG

'168 supplies SNI‑based interception and apply‑policy‑before‑forwarding‑the‑ClientHello plus explicit decrypt‑on‑match / allow‑without‑decryption limitations (claims 3 and 9). IPUG supplies the priority‑ordered decrypt/bypass policy table and bypass lists. Motivation: '168 is expressly about conserving computational resources during handshake ("computational resources required to decrypt and re‑encrypt the data can be conserved"), which is the same problem the '777 specification states verbatim ("SSL/TLS proxies are computer‑resource intensive…"). Where a reference identifies the problem and another supplies the conventional administrative mechanism for exploiting a pre‑decryption predicate, the combination is a textbook KSR "predictable variation."

Ground 3 — IPUG + Buruganahalli + (secondary) US 2017/0279782 (if §102(a)(2)‑qualified)

This is the ground that most directly reaches the efficiency/selective‑decryption framing. IPUG supplies the decrypt/bypass policy architecture and priorities; Buruganahalli supplies SNI‑and‑certificate extraction with the whitelist/blacklist decrypt decision; US 2017/0279782 supplies the express policy‑driven "sensitive stays encrypted / other traffic is decrypted and examined" rationale, which is precisely the '777's stated privacy‑vs‑security tradeoff. Motivation: marketplace and policy pressure — the record shows POSITAs of the era consulted vendor documentation of exactly these products (the IPR declarant names Cisco, BlueCoat, Sophos, Trend Micro, Palo Alto Networks, and a 2014 Network World review noting that "other requests not subject to the policy are forwarded to the external destination server").

Ground 4 — Evevang (US 2003/0088787) + Buruganahalli

Evevang was the Examiner's anticipation reference against the '526 application. If Evevang discloses the list/compare/action structure (as the Examiner found), Buruganahalli supplies the TLS‑specific SNI/certificate predicate and the conditional‑decrypt step, and IPUG supplies the policy‑table/priority implementation. Note: the §101 rejection and the Evevang §102 rejection were both overcome by a January 14, 2019 amendment that rewrote independent claims 1 and 11 into the two‑list/priority form — i.e., the '526's allowance turned on the two‑list ordering, not on selective decryption per se. That is the same pressure point identified in §3.

Ground 5 — Check Point R77.30 + IPUG (with Buruganahalli for SNI/CN)

The ITC Commission affirmed that R77.30 discloses "creat[ing] the list of the identification data based on the received at least one list of network addresses and/or domain names," reasoning that category‑based rules from a subscription service determine what traffic to decrypt and inspect, and affirmed the Final ID's finding that '526 claims 1, 3, 11, 13, 16 are invalid as anticipated under §102. For the '777 — a continuation of that same specification — this is highly probative: a §102 anticipation of the parent's independent claim on the same disclosure is a strong indication that the '777's analogous claims, absent some narrower two‑stage URI‑gate limitation, would be at least obvious over R77.30 + IPUG.

Where the record is weakest against the '777

The distinctively narrow limitation is the post‑decryption URI gate that re‑encrypts and routes packets around the MITM when the URI does not match. A Petitioner must show either (a) that a reference or the general knowledge discloses applying a URI predicate after decryption to decide whether the plaintext continues to the inspection engine, or (b) that it would have been obvious to do so as a resource‑saving measure. The best route to (b) is Buruganahalli's own resource‑conservation rationale plus IPUG's URL‑filtering categorization applied to a decrypted flow, plus the well‑known "fast‑path/slow‑path" design pattern — but note that the Petitioners themselves conceded IPUG could not specify a URI in its Decryption Policy. That concession is the strongest available nonobviousness argument for Centripetal, and a careful Petitioner must rebut it by arguing that efficiency‑driven placement of an already‑known URL filter downstream of a decrypt decision is an ordinary design choice, not an inventive leap.

5. Motivation‑to‑combine — the affirmative case

1. Same field, same problem, same mechanism. All primary references (Buruganahalli, '168, IPUG, R77.30) are in inline network‑security appliances dealing with TLS‑encrypted traffic and use a pre‑decryption identity predicate from the handshake.
2. The '777's own specification supplies the motivation. It concedes: "Typically, an SSL/TLS proxy decrypts all of the SSL/TLS‑secured communications passing through it… this may be undesirable and inefficient," and it identifies CAPEX/OPEX and end‑user degradation as the drivers. Under KSR, an express statement of the problem plus references offering the solution is a strong motivation.
3. Predictable result. Selective decryption based on a list is an anticipated functional outcome: "not decrypting a session if the destination domain is on the whitelist, and decrypting a session if … on the blacklist" (Buruganahalli) is the same result as '777 Step 1‑5a/1‑5b.
4. Ordinary engineering design choice for the two‑stage structure. Using a cheap test first and an expensive test second to avoid unnecessary work is a ubiquitous optimization pattern, and the '777 itself characterizes its benefit as "deterministically more efficient" — a quantitative improvement of a known technique, which KSR classifies as an obvious design choice absent unexpected results.
5. Marketplace demand. The 2014 Network World article and the vendor‑documentation practice evidenced in the IPR record show a POSITA would have consulted, and adapted, these products' policies.

6. Counterarguments Centripetal would raise (and my assessment)

• No URI in the pre‑decryption decision: not a saving limitation — the '777's own claim (assumed) uses the domain/cert for the decrypt decision and the URI only after decryption, so this argument actually supports the mapping.
• Teaching away / "obscured" efficiency: the "unnecessary decryption" scenario at Step 1‑5b is expressly conceded in the specification, with the justification that the process is "deterministically more efficient" overall. That is an assertion, not evidence of unexpected results; no secondary‑considerations evidence appears in the retrieved record for the '777.
• §101 overlay: independent of §103, the '526 application was rejected under §101 on Oct. 12, 2018 as "directed to the abstract idea of efficient SSL/TLS proxy," and Keysight moved to dismiss the earlier family patents under §101. Any §103 analysis for the '777 should be paired with a §101 posture assessment.
• Family validity signals cut against the patent owner: the ITC anticipation finding on '526 claims 1/3/11/13/16, the prior IPR written decisions on Centripetal patents (IPR2018‑01386, ‑01443, ‑01444, ‑01505, ‑01506, ‑01513), and the January 2019 amendment‑driven allowance together suggest a narrow allowance basis — the two‑list priority ordering (parent claim 7) and the URI‑derived‑host‑name feature — rather than selective decryption broadly.

7. Explicit uncertainties

1. No "Prior Art section" was supplied in the material I was given; the reference set above is my reconstruction from the retrieved citation/litigation record, not from the '777's front page.
2. The '777's claims were not retrieved verbatim. The element‑by‑element chart in §3 is against an assumed claim set inferred from the parent '526 (whose claims I did retrieve) and from the reported language of US 12,034,710. Claim count, antecedent basis, and whether the '777 claims a two‑stage URI gate at all are unverified.
3. US 9,419,942 B1's identifiers need a check. The search result labeling it "US Patent No. 7,185,356 to Buruganahalli" appears to be an exhibit‑label error — the disclosed content, filing date (2013‑07‑25), issue date (2016‑08‑16), and claim text all match the '942 patent. Do not propagate the '356 number.
4. US 2017/0279782 A1 published 2017‑09‑28, after the '777's asserted 2017‑07‑24 priority date. Its availability depends on an earlier effective filing date; verify before citing it.
5. The '526 IPR petition number. The petition/declaration I retrieved (ptacts asset jkPSl135…/6kYpY9RE…) is a third‑party IPR against the '526 using IPUG as Exhibit 1008; I could not confirm the docket number or petitioner within the available steps. The Keysight IPRs I could confirm are IPR2022‑01097 (on the '917) and IPR2022‑01199 (with an exhibit charting Buruganahalli); the Keysight IPR on the '526 is referenced but not numbered in my results.
6. No obligation to prove a negative: to convert §4's grounds into an actual invalidity position, the '777 claim text, its file wrapper (IDS, examiner's cited art, any 892/1449), and any post‑issuance IPR/PGR must be pulled from USPTO PatentCenter for application 16/356,421 (publication US 2020/0304476 A1).

8. Bottom line

On the assumed claim scope, the '777's core — list of identification data + corresponding action; detect flow; extract SNI and/or certificate CN in the clear; compare to a domain list; selectively decrypt on match and route around the decrypt path on no‑match; apply an action and re‑encrypt — is squarely disclosed by US 9,419,942 B1 (Buruganahalli), alone or in view of the Cisco IronPort AsyncOS 7.1 Web User Guide, and further reinforced by US 9,237,168 B2 and by the Check Point R77.30 art that the ITC already used to hold parent '526 claims 1, 3, 11, 13, 16 anticipated. The motivation to combine is strong on this record because every reference attacks the same problem the '777 specification names — the cost of decrypting all TLS traffic — and the '777's asserted benefit is characterized as a deterministic efficiency improvement rather than an unexpected technical effect.

The one limitation that resists easy §103 treatment is the two‑stage gate: decrypt after a domain match, then compare the decrypted URI and bypass the MITM on a URI miss. That is where a Petitioner should focus its motivation‑to‑combine evidence (fast‑path/slow‑path semantics; Buruganahalli's conservation rationale; IPUG's downstream URL filtering), and where Centripetal's best nonobviousness argument lives — aided by the Petitioners' own concession that IPUG could not place a full URI in a pre‑decryption policy.

All of this is provisional pending retrieval of the actual claim text of US 11,233,777.