US 11693685

I'll search for authoritative information on this specific patent number and any litigation involving it.

Let me search for the specific IPR outcome and any Federal Circuit appeal involving this patent.

US Patent 11,693,685 B2 — Patent Analysis

Important scope note: I searched for the literal identifier "11693685" / "11,693,685" and confirmed it maps to the Orca Security patent below. I did not find any Court of Appeals for the Federal Circuit docket for this patent in 2026. What I found instead is a PTAB (not CAFC) final written decision in IPR2024-00865, plus a Delaware district court case that was dismissed. I flag this explicitly because your request asked specifically for CAFC 2026 dockets — I cannot confirm any such appeal exists, and I will not fabricate one.

1. Bibliographic Data

Source: https://patents.google.com/patent/US11693685/en

2. Abstract (verbatim)

"A system and method for securing virtual cloud assets in a cloud computing environment against cyber threats. The method includes: determining a location of a snapshot of at least one virtual disk of a protected virtual cloud asset, wherein the virtual cloud asset is instantiated in the cloud computing environment; accessing the snapshot of the virtual disk based on the determined location; analyzing the snapshot of the protected virtual cloud asset to detect potential cyber threats risking the protected virtual cloud asset; and alerting detected potential cyber threats based on a determined priority."

3. Plain-Language Overview of the Independent Claims

Claim 1 — System. A processor is programmed to: (a) set up an interface between a "client environment" (e.g., a cloud tenant account) and security components; (b) through that interface, use the cloud provider's APIs to identify the virtual disks of a VM running in the client environment; (c) use those same APIs to ask where at least one of those disks physically/logically lives; (d) receive back that location; (e) generate at least one snapshot of the VM's disks; (f) analyze the snapshot to detect both vulnerabilities and sensitive data — with the express requirement that the analysis needs no interaction with the VM (i.e., agentless, VM-independent); (g) compute a risk level for the VM; and (h) report the findings as alerts that are filtered and prioritized according to that risk level.

Claim 13 — Method. The same sequence of steps cast as a computer-implemented method, with one notable wording difference: instead of "generate at least one snapshot," the method claim recites "emulating the virtual disks of the virtual machine to generate at least one snapshot."

Claim 22 — Non-transitory computer-readable medium. Instructions that, when executed, cause a computing device to perform the same steps as claim 13, again using the "emulate the virtual disks … to generate at least one snapshot" phrasing.

Notable dependent-claim coverage (for context): claim 2 (VM inactive during analysis; snapshot includes memory page file), claim 3 (page file used to deduce running applications), claim 4 (VM active during analysis), claims 11–12 (detect installed applications/keys and non-secure configurations), claim 9 (multiple snapshots on a schedule), claim 10 (snapshot on a trigger event).

4. Litigation and PTAB History (as found in the dockets)

• Delaware District Court: Orca Security Ltd. v. Wiz, Inc., No. 1:23-cv-00758 (D. Del., filed July 12, 2023; Judges Jennifer L. Hall and Sherry R. Fallon). US 11,693,685 was one of six asserted Orca patents (alongside 11,663,031; 11,663,032; 11,726,809; 11,740,926; 11,775,326). The case was stayed pending IPR (order entered Jan. 16, 2025) and then dismissed with prejudice by stipulation, with the case terminated on Jan. 13, 2026. (CourtListener docket 67600951, D.I. 233, 237/238.)
• PTAB: Wiz, Inc. v. Orca Security Ltd., IPR2024-00865 (petition filed May 24, 2024; challenging claims 1–22). Institution granted Dec. 9, 2024 (panel: APJs Zecher, Baer, Raevsky). Per the parties' joint notice to the district court, the PTAB issued a Final Written Decision on December 8, 2025 finding all claims of the '685 patent unpatentable (together with the '031 and '032 patents). (D. Del. D.I. 235.)
• Federal Circuit: The joint notice states the deadline for a notice of appeal to the CAFC was February 9, 2026, and the deadline for rehearing/director review was January 7, 2026. I found no record of an actual CAFC appeal for the '685 patent in the search results returned. If an appeal was filed, I do not have authoritative confirmation, and I am flagging that as an open question rather than asserting either way.
• Google Patents' Darts-ip entry separately lists a "first worldwide family litigation" (family 71731840) and a Delaware case link for 1:23-cv-00758.

5. Confidence / Uncertainty Flags

• High confidence on bibliographic data, abstract, claim text, issue date, inventor, assignee, filing/priority dates — all taken from the patent document itself in the full text provided.
• High confidence on the existence of IPR2024-00865, its institution, and the December 8, 2025 Final Written Decision finding the claims unpatentable — corroborated by two independent sources (the parties' D.I. 235 joint notice; CourtListener/PACER entries; Docket Alarm).
• Lower confidence / unverified: whether Orca actually filed a CAFC appeal by the Feb. 9, 2026 deadline. No docket was surfaced.
• Data-vendor artifact caveat: One Docket Alarm listing showed presiding "judges" for IPR2024-00865 as "Daniel Galligan, Garth Baer, Michael Zecher, Scott Raevsky," which conflicts with the PTAB institution decision naming only Zecher, Baer, and Raevsky. The PTAB document is the more authoritative source for panel composition.
• The Google Patents page still shows legal status "Active" and anticipated expiration 2039-09-27; that status display does not appear to reflect the December 2025 adverse PTAB ruling.

Bottom line: US 11,693,685 is an Orca Security (Avi Shua) continuation patent on agentless cloud VM inspection via disk snapshots, claiming the API-driven disk-location-and-snapshot workflow with risk-based alert prioritization. It was asserted by Orca against Wiz in Delaware, was subject to IPR2024-00865, and its claims were held unpatentable by the PTAB on December 8, 2025. The district court case was dismissed with prejudice in January 2026. I found no CAFC 2026 docket for this patent.

I'll research the litigation history for US patent 11693685. Let me search multiple sources.

Let me dig deeper into the outcomes of both the district court case and the IPR proceeding.

Litigation Involving U.S. Patent No. 11,693,685 ("the '685 patent")

Based on my search of patent litigation sources (Unified Patents litigation portal, Docket Alarm, CourtListener/RECAP, and PTAB records), I identified two proceedings that directly involve U.S. Patent No. 11,693,685. Both arise from the same commercial dispute between Orca Security Ltd. and Wiz, Inc.

1. District Court Litigation

Relevance of the '685 patent: Orca asserted the '685 patent as one of six patents in the case (U.S. Patent Nos. 11,663,031; 11,663,032; 11,693,685; 11,726,809; 11,740,926; and 11,775,326). Wiz filed counterclaims asserting infringement by Orca of five Wiz patents (U.S. Patent Nos. 11,722,554; 11,929,896; 11,936,693; 12,001,549; and 12,003,529).

Key procedural timeline:

• July 12, 2023 — Complaint filed.
• October 10, 2023 — Second Amended Complaint (six Orca patents).
• May 24, 2024 — Wiz filed IPR petitions (including IPR2024-00865) against the '031, '032, and '685 patents.
• December 9, 2024 — PTAB instituted review of the '031, '032, and '685 patents.
• January 16, 2025 — Court stayed the district court action pending the IPRs.
• December 8, 2025 — PTAB issued Final Written Decisions in IPR2024-00863, -00864, and -00865, finding all claims of the '031, '032, and '685 patents unpatentable (reported to the court via joint notice, Dec. 15, 2025).
• January 13, 2026 — Stipulation of dismissal with prejudice entered; case closed.

Source: Orca Security Ltd. v. Wiz, Inc., No. 1:23-cv-00758 (D. Del.); https://portal.unifiedpatents.com/litigation/Delaware%20District%20Court/case/1%3A23-cv-00758 ; https://www.courtlistener.com/docket/67600951/orca-security-ltd-v-wiz-inc/

2. Inter Partes Review (PTAB)

Source: Wiz, Inc. v. Orca Security Ltd., IPR2024-00865 (PTAB); https://portal.unifiedpatents.com/ptab/case/IPR2024-00865 ; see also PTAB Decision Granting Institution and Joint Notice of FWDs (D.I. 235) filed in D. Del. C.A. No. 23-758.

Notes and Cautions

1. "Unified Patents" on the Google Patents front page is a data-source label, not the petitioner. The Google Patents record lists the litigation with the label "Unified Patents PTAB Data." The actual IPR petitioner was Wiz, Inc., not Unified Patents, per the PTAB papers and Docket Alarm records. I flag this because the label could be misread as identifying who filed the petition.

2. Related but distinct IPRs. Wiz filed parallel PTAB challenges against other Orca family patents — IPR2024-00863 ('031), IPR2024-00864 ('032), IPR2024-01190 ('926), IPR2024-00220 ('735, denied institution after Orca disclaimed the challenged claims), and others. These do not involve the '685 patent and are listed here only for context.

3. No other litigation identified. I found no separate or additional court actions (e.g., ITC, other district courts, or foreign proceedings) in which the '685 patent itself was asserted or challenged. If any exist, they were not surfaced in the sources searched.

Disclaimer

This is a summary based on publicly available docket and PTAB records retrieved on the current date and is provided for informational purposes only — it is not legal advice. Docket statuses, appeal outcomes, and any post-FWD Federal Circuit activity should be verified directly against PACER, the PTAB's PTAB End-to-End system, and the CAFC docket before being relied upon.

I'll research this patent's PTAB history. The structured block flags one proceeding — IPR2024-00865 — so let me dig into that and check for others.

Strong signal: web search surfaced IPR2024-00865 (Wiz v. Orca) despite the ODP block showing nothing. Let me nail down the FWD outcome, appeal status, and grounds.

⚠️ Data-source conflict — flagged first

The structured "PTAB proceedings on file" block states the USPTO ODP API returned no AIA trial proceedings for US 11,693,685. That ingest appears incomplete. Both the patent's own Google Patents litigation metadata and multiple public court/PTAB filings establish that this patent was the subject of IPR2024-00865, which ran to a Final Written Decision in December 2025. Per the operating rules I am treating the web/court-record evidence as controlling and flagging the ODP gap. I did not obtain the FWD directly from PTAB E2E (the FWD was filed under seal in the district court), so the claim-level outcome below rests on the parties' joint notice to the district court rather than my own reading of the opinion.

Proceedings overview

Total: 1 AIA trial proceeding on US 11,693,685 — status breakdown: 1 claims-invalidated (FWD issued 2025-12-08, all claims held unpatentable); 0 active, 0 sustained, 0 settled at the PTAB, 0 institution-denied.

Bottom line for a defendant: every claim of this patent — claims 1–22 — was held unpatentable in a final written decision, and the parallel district court case was dismissed with prejudice. If a demand letter today cites US 11,693,685, the patent owner is asserting claims that have been adjudicated invalid; absent a successful Federal Circuit reversal, there is no live case built on this patent.

IPR2024-00865 — Wiz, Inc. v. Orca Security Ltd.

• Type: Inter Partes Review (35 U.S.C. §§ 311–319)
• Filed: 2024-05-24 (petition); PTAB notice of filing date 2024-06-13
• Status: Final Written Decision issued 2025-12-08 — all challenged claims (1–22) unpatentable. (Note: the structured ODP block lists no proceeding; Google Patents' litigation block records this case as "PTAB case IPR2024-00865 filed (Final Written Decision)".)
• Judge panel: At institution — Michael R. Zecher (writing), Garth D. Baer, and Scott Raevsky, Administrative Patent Judges. Third-party docket data additionally lists Daniel J. Galligan on the panel for this proceeding; I could not independently confirm the exact composition at the time of the FWD. Treat the panel as unsettled.
• Petition grounds: Challenged claims 1–22 of the '685 patent. Grounds were § 103 obviousness-based, with Veselov (U.S. Patent No. 11,216,563, assigned to Amazon, filed 2017-05-19) as the primary prior art reference — confirmed by the district court record: "Wiz filed IPRs that included as a primary prior art reference a patent assigned to Amazon … Veselov" and "All six IPR petitions rely on the same primary prior art reference." The specific secondary/tertiary references used in this petition (as opposed to the companion petitions) are not confirmed in the materials I retrieved — I am not going to attribute the '031 patent's Veselov + Price + Hufsmith + Huseinovic ground structure to '685. No § 112 or § 102 challenge is documented in the sources I found.
• Institution decision: Instituted 2024-12-09 (Paper 8) as to claims 1–22. The panel held it was "reasonably likely that Wiz would prevail in demonstrating at least one of claims 1-22 of the '685 patent is unpatentable," applying the § 314(a) threshold. Orca's § 325(d) discretionary-denial arguments did not carry the day. Statutory FWD deadline was therefore 2025-12-09.
• Final Written Decision: Issued 2025-12-08. Per the parties' Joint Notice of Inter Partes Review Final Written Decisions (D. Del. D.I. 235), the PTAB "issued Final Written Decisions in IPR2024-00863, IPR2024-00864, and IPR2024-00865, finding all claims of Orca's Asserted U.S. Patent Nos. 11,663,031, 11,663,032, and 11,693,685 unpatentable." For '685 that means claims 1–22 — the entire claim set, including independent claims 1 and 13 and all dependents — were held unpatentable. No claim was held patentable. Secondary press reporting characterizes the FWDs as resting on lack of novelty or obviousness over prior art. I do not have the panel's verbatim reasoning for '685 (the FWD was filed under seal as Exhibit C to D.I. 235), and I will not paraphrase reasoning I have not read. No motion to amend was granted in the documents I reviewed.
• Settlement / termination: No PTAB settlement. The district court action was stayed 2025-01-16 (D.I. 233) pending the IPRs, and then dismissed with prejudice 2026-01-13 (D.I. 238) by stipulation, with the parties agreeing to bear their own fees and not to re-assert these claims. Any underlying commercial terms are confidential. Note the PTAB proceeding itself was not terminated by the dismissal — it had already run to FWD.
• Appeal: No Federal Circuit appeal confirmed as of 2026-09-29. The deadline for a Notice of Appeal was 2026-02-09 (and for rehearing/Director Review, 2026-01-07). I found no CAFC docket addressing IPR2024-00865. Given the 2026-01-13 dismissal-with-prejudice and mutual no-reassertion agreement, an appeal is unlikely, but I cannot rule it out — this is a genuine open question, not a negative finding I can make with high confidence. If no appeal was filed, the Director's certificate cancelling claims 1–22 would issue in roughly the February–March 2026 window.
• Defensive value: This is about as strong as it gets — the entire patent is invalidated, so any infringement theory built on '685 faces a final PTAB judgment of unpatentability. Confirm that the certificate of cancellation has issued (or that no appeal was filed by 2026-02-09) before relying on it, and note that a § 315(e)(1) estoppel binds Wiz and its privies, not every defendant — but a preclusive-style Article III judgment and the resulting cancellation are different from IPR estoppel and are what actually doom the patent here.

Strategic summary

Claim status. All claims of US 11,693,685 — claims 1 through 22 — are CANCELED (adjudicated unpatentable on 2025-12-08; cancellation becomes formal on issuance of the Director's certificate absent appeal). There are zero SUSTAINED claims and zero UNTESTED claims on this patent. Every claim in the printed patent was within the scope of the challenge. Practically, the patent is no longer an assertion vehicle.

Estoppel landscape. As to the PTAB, § 315(e)(1) bars Wiz, Inc. (and its privies/RPIs) from requesting or maintaining a proceeding before the Office on any ground raised or that reasonably could have been raised in IPR2024-00865, and § 315(e)(2) bars Wiz from asserting in civil litigation that a claim is invalid on any such ground. That estoppel does not run against unrelated defendants. For a different defendant, the practical point is not estoppel but judgment: the FWD plus the district court's dismissal with prejudice transform the patent's posture fundamentally. If you are evaluating the '685 patent today, the primary available defenses are (i) the patent is invalidated and/or canceled, and (ii) if the certificate has not yet issued, the FWD is highly persuasive but not technically self-executing against a non-party. Prior-art grounds beyond what Wiz raised remain available to you as a matter of form, but you would be litigating against a patent whose entire claim set has already fallen.

Pattern signals. Wiz, Inc. was a serial petitioner across the same Orca family, challenging all six asserted patents with the same primary reference (Veselov): IPR2024-00863 ('031), IPR2024-00864 ('032), IPR2024-00865 ('685), IPR2024-01109, IPR2024-01190 ('926), and IPR2024-01191 ('326) — plus an earlier IPR2024-00220 against the '735 patent that was institution-denied because Orca disclaimed all challenged claims. Orca fought hard on the merits (substantial POPRs, successful motions for additional discovery on objective indicia, closed consolidated oral argument on 2025-09-15) rather than settling at the Board. No defensive aggregator (e.g., Unified Patents) is in the chain for this patent — the Google Patents "Unified Patents PTAB Data" annotation is a data source citation, not an indication that Unified Patents filed here; the petitioner of record is Wiz. Orca also went on offense, filing IPR2025-01083 through -01087 against Wiz's patents with Sotera stipulations — an aggressive, non-settling posture on both sides. On the merits, Orca pursued disclaimers as a defensive tool in the family (the '735 patent), which is relevant pattern context.

Recommended next steps

• If you are a defendant: obtain the redacted public FWD in IPR2024-00865 from PTAB E2E (https://ptacts.uspto.gov/ptacts/) and confirm the claim-by-claim disposition and whether a request for rehearing (due 2026-01-07) or Notice of Appeal (due 2026-02-09) was filed. The institution decision is publicly available via the district court record: https://www.docketalarm.com/cases/Delaware_District_Court/1--23-cv-00758/Orca_Security_Ltd._v._Wiz_Inc/docs/218/3.pdf
• The parties' Joint Notice of the FWDs (the dispositive document for claim-level outcome) is at https://archive.org/download/gov.uscourts.ded.83027/gov.uscourts.ded.83027.235.0.pdf — it states the FWDs found "all claims" of the '031, '032, and '685 patents unpatentable.
• Verify the certificate of cancellation / Director's certificate for claims 1–22 of the '685 patent. That is the operative event for the patent's death; without it, you are relying on an unappealed but not-yet-certified FWD.
• No trial-stage milestones remain on this patent: institution 2024-12-09, oral argument 2025-09-15, statutory FWD deadline 2025-12-09, FWD issued 2025-12-08. The only open procedural item is the (likely lapsed) appeal window.
• Diligence the three companion proceedings on the sibling patents — IPR2024-01109, IPR2024-01190, and IPR2024-01191 had FWDs expected in early 2026 — because a defendant facing a family-wide assertion needs the whole picture, not just the '685 outcome. Fetch the underlying FWDs rather than relying on press summaries; I have not independently read the IPR2024-00865 opinion and have deliberately avoided attributing the companion '031-record reasoning (Veselov + Price, "alerts" and "inactive VM" limitations) to '685.

I'll start by researching the assignment records, litigation history, and company status for US 11693685.

Let me dig into the specific assignment records and company background.

Ownership & Assignment Analysis — US 11,693,685 B2

Patent: US 11,693,685 B2 ("Virtual machine vulnerabilities and sensitive data analysis and detection")
App: 17/361,861 · Filed: 2021-06-29 · Granted: 2023-07-04 · Priority: 2019-01-28 (prov. 62/797,718)
Verification search: USPTO Assignment Center / USPTO Assignment Search — query "11693685".

Sourcing note: two live fetches to Assignment Center were cut off by the tool's step limit, so reel/frame data below is drawn from the patent's own front-matter legal events (Google Patents, authoritative copy in this record) plus the USPTO Patent Center / PTAB file documents surfaced in search. I flag the one gap explicitly rather than guess. I did not invent any reel numbers.

Inventors

• Avi Shua — sole named inventor. Address of record: Tel Aviv / Tel Aviv‑Jaffa, Israel; post‑office address given as c/o Orca Security LTD., 65 Yigal Alon St., Tel Aviv 6744316, Israel.
  • Employer at filing: Orca Security Ltd. (he is a co‑founder and CEO). In a recorded investor presentation (PTAB Ex. 2079, Orca Security, YL Ventures CISO Startup Connection), Shua states Orca was founded in 2019 by eight co‑founders "all out of Check Point executive and architects," and that he was "the previous chief technologist in Check Point."
  • Pattern check — departures within 12 months: Not present. The inventor is the founder/CEO and remained with the assignee through the litigation (he is quoted in Orca's own PTAB/litigation exhibits through 2025). No inventor-departure-before-fire‑sale tell.
  • The "eight co‑founders" statement is about the company, not inventorship — do not conflate the two. Only Shua is named on this patent.

Original assignee

• Orca Security Ltd. — Israeli corporation, HQ Tel Aviv (65 Yigal Alon St. at the time of the 2019 assignment; later Hartom/HaMaser St., Tel Aviv‑Yafo 6721714 per the 2022 Application Data Sheet).
• Business: cloud‑native security. Flagship is the Orca Cloud Security Platform, built on its patented SideScanning™ technology — agentless, out‑of‑band reading of cloud workloads' virtual disks/config to detect vulnerabilities, misconfigurations, and sensitive data. That is precisely the subject matter of claim 1 of the '685 patent.
• Does it ship a product embodying the claims? Yes. The '685 claim set (querying cloud APIs for a VM's virtual disk location, snapshotting, analyzing with no interaction with the VM, risk‑scoring, prioritized alerting) is the description Orca gives of SideScanning in its own marketing and in its pleadings, and Orca argued "patent‑practicing SideScanning™ technology" and "commercial success" to the PTAB in the parallel IPRs (e.g., PO request for discovery, IPR2024‑01109). This is a real revenue‑generating product, not a licensing shell.
• Status: Operating. Private, VC‑backed. Recorded seed round of $6.5M (YL Ventures era, 2019); later a Series C extension led by Temasek per an Orca exhibit (Ex. 2088). No bankruptcy, dissolution, or acquisition found in the sources retrieved. Litigation‑disclosure statement in D. Del. lists "No Parents or Affiliates."

Assignment timeline

Only inventor→company assignments are recorded. There is no post‑issuance transfer, securitization, or third‑party conveyance. Two recording events appear:

• 2019-09-26 (executed) / recorded 2019‑09‑27 — Reel 050520/0770

  • Conveyance: Assignment (combined "Declaration and Assignment for Patent Applications")
  • Assignor: Avi Shua (sole inventor)
  • Assignee: Orca Security Ltd., 65 Yigal Alon St., Tel Aviv 6744316, Israel
  • Correspondent: Not confirmed from retrieved sources. The issued‑patent face names Finnegan, Henderson, Farabow, Garrett & Dunner, LLP as attorney/agent of record, while a family power of attorney appoints "all attorneys and agents of M&B IP Analysts, LLC." I could not verify which recorded on the assignment — flagged, not asserted. (Neither firm recurs across a multi‑link chain here, so the recurrence tell is moot.)
  • Context: Standard founder/employee IP assignment taken at company formation, covering the parent application 16/585,967 (which issued as US 11,431,735). Signature dated 09/26/2019; effective date recorded as 2019‑09‑26. This reel/frame is confirmed via the patent's Legal Events.

• Recorded 2021‑12‑06 — Reel/Frame not surfaced

  • Conveyance: Assignment ("ASSIGNMENT OF ASSIGNORS INTEREST; SEE DOCUMENT FOR DETAILS")
  • Assignor: Avi Shua
  • Assignee: Orca Security Ltd.
  • Correspondent: Not surfaced.
  • Context: Confirmatory/continuation assignment recorded for the '861 continuation application (~5 months after its 2021‑06‑29 filing). Same parties as the 2019 instrument — not a transfer to a third party. Reel/frame not captured; verify in Assignment Center.

Full family check: all 13 applications in family ID 71731840 remain Orca‑owned; none has been conveyed out.

Timeline diagram

timeline
    title Ownership of US 11693685
    2019 : Orca Security founded
         : Inventor Shua assigns rights to Orca
    2021 : Continuation application filed
    2023 : Patent issued to Orca Security Ltd
         : Orca sues competitor Wiz in D Delaware
    2024 : Wiz petitions for inter partes review
    2025 : PTAB holds all claims unpatentable
    2026 : District case dismissed with prejudice

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT. No "IP / Holdings / Licensing / Ventures" LLC anywhere. Recorded assignee is Orca Security Ltd. (reel 050520/0770 and the 2021‑12‑06 recording), an Israeli operating company at a real Tel Aviv business address, not a registered‑agent mailbox.
2. Known asserter in the chain — NOT PRESENT. No Acacia, Marathon, Intellectual Ventures, Wi‑LAN, Conversant, Pendrell, Round Rock, Spangenberg, etc. Chain begins and ends with Orca. Note: Wiz is the defendant/petitioner, not an owner — Wiz is not in the chain.
3. Repeat correspondent across the chain — NOT PRESENT (single link). Only one transferor→transferee pair exists, so no recurrence test can be satisfied. The prosecution firms (Finnegan Henderson; M&B IP Analysts) do not recur as recording correspondents.
4. Cascading transfers — NOT PRESENT. One substantive assignment (2019), one confirmatory recording (2021). No chained LLC hops within 24 months.
5. Pre-litigation transfer — NOT PRESENT. Assignment executed 2019‑09‑26; first suit (Orca v. Wiz, D. Del. 1:23‑cv‑00758) filed 2023‑07‑12 — ~46 months later. The plaintiff is the original assignee. No set‑up transfer before filing.
6. Bankruptcy fire‑sale — NOT PRESENT. No Chapter 7/11, no assignment to a liquidation vehicle.
7. Privateering — NOT PRESENT. Orca asserts its own patents against a direct competitor (Wiz) in a two‑way fight; Wiz counterclaimed for infringement of Wiz's own patents ('554, '896, '693, '549, '529). That is competitor‑vs‑competitor assertion, not an operating company arming a proxy NPE.
8. Defensive aggregator — NOT PRESENT. Chain does not terminate at RPX, AST, LOT, Unified Patents, or OIN. (Wiz's IPRs are party‑filed challenges, not a defensive‑aggregator acquisition. Note: the Google Patents "Petitioner: Unified Patents" label is a data‑source label, not the petitioner — the actual petitioner of IPR2024‑00865 is Wiz, Inc.)

Verdict

Operating-company assertion.

Orca Security Ltd. is the original assignee and still the owner, per reel 050520/0770 (executed 2019‑09‑26) and the 2021‑12‑06 recording, with no downstream transfer or shell step in between. It is a real operating vendor whose flagship SideScanning product practices the claimed agentless snapshot‑inspection technique, and it used the '685 patent to sue a direct competitor, Wiz, in D. Del. 1:23‑cv‑00758 on 2023‑07‑12 — the textbook operating‑company‑versus‑competitor profile, not an NPE pattern.

Post‑script (relevant to value, not classification): the assertion ultimately failed — the PTAB instituted IPR2024‑00865 and on 2025‑12‑08 issued a Final Written Decision holding all claims unpatentable, and the district court entered a stipulation of dismissal with prejudice on 2026‑01‑13. So while there is no NPE signal in the ownership chain, the '685 patent has been effectively neutralized on validity grounds.

Verify at: https://assignmentcenter.uspto.gov/ (search US11693685) — re‑query the 2021‑12‑06 recording to capture its reel/frame, which my sources did not surface.

I'll verify the key prior-art references against authoritative sources before analyzing them.

Let me verify the other key cited references.

Prior-Art Analysis — US Patent No. 11,693,685 B2

Identifier check (per strict rule): Searching the literal ID "11693685" returns exactly one match — US 11,693,685 B2, app. 17/361,861, "Virtual machine vulnerabilities and sensitive data analysis and detection," Orca Security Ltd. (inventor Avi Shua). I did not substitute any similar number (e.g., not 11,693,693 / 11,663,685 / 11,636,855). Confirmed against the patent document text and Google Patents: https://patents.google.com/patent/US11693685/en

Important caveat on "anticipation" framing: The task asks which claim(s) each reference "potentially anticipates" under § 102. Anticipation requires that a single reference disclose every element of a claim. Very few cited references do that cleanly for the independent claims; most are better characterized as § 102 partial-art or § 103 art. I mark the two strongest standalone-anticiption candidates and flag the rest as element-level art. I also flag where I am inferring mapping rather than quoting the examiner's own reasons (the prosecution reasons-of-allowance are not in the provided record).

1. Legal framework / critical date

Every reference listed in the patent's "Citations" section predates 2019-01-28, so all qualify at least as § 102(a)(1)/(a)(2) art.

2. Tier 1 — Highest-relevance references (strongest § 102 candidates)

2.1 US 2017/0111384 A1 (Loureiro & Donnat), SecludIT — the closest art

• Full citation: US 2017/0111384 A1, "Method for detecting vulnerabilities in a virtual production server of a virtual or cloud computer system," Sergio Loureiro & Frédéric Donnat, assignee SecludIT (Valbonne, FR). Filed 2016-10-12 (App. 15/291,776); published 2017-04-20; FR priority 1502184, 2015-10-16. Granted as US 10,412,109 B2 (2019-09-10, Outpost 24 France).
• Brief description: An agentless vulnerability scanner outside the cloud connects to the cloud platform and, using the platform's API/cloning functions, requests a clone or disk copy of the virtual production server; then connects to and analyzes the clone/disk copy (Nessus/OpenVAS/Metasploit checks, log analysis, checksums, malware presence), generates a report, and erases the copy. It expressly does not require an agent or admin keys on the production server. Expressly notes that when a disk image is used "the server is not in execution mode" — malware is not executed during analysis.
• § 102 mapping:
  • Claim 1/13/22 — element-by-element: interface to cloud platform (a) ✓; use of cloud APIs to identify/locate the virtual disks (b, c, d) ✓; disk copy/clone = snapshot (e, and the method/CRM "emulating the virtual disks … to generate" variant) ✓; analysis of the copy with no cooperation from the production VM (f) ✓; report generation (h-format) ✓. Weak gap: SecludIT's disclosure does not clearly recite a computed "risk level of the virtual machine" that filters/prioritizes alerts, nor "sensitive data" detection as such — so a purist § 102 read may not take independent claims 1/13/22 in their entirety, though it is devastating § 103 art combined with a risk-scoring reference.
  • Given the gaps above, SecludIT is strongest against claims 1–10 and 13–21 at the element level, and is the anchor reference any invalidity theory would lead with.
• Corroboration that this is the art that matters: Wiz used this exact reference as Exhibit 1097 in IPR2024-01190 and in related Orca patent IPRs (IPR2024-00865 family), per the Docket Alarm exhibit file: https://www.docketalarm.com/cases/[PTAB](/ptab)/IPR2024-01190/Wiz_Inc/docs/07-31-2024-Petitioner/Exhibit-1097-Loureiro___US20170111384A1.pdf

2.2 US 2013/0247133 A1 / US 8,850,512 B2 (Price & Bettini), McAfee — strong second

• Full citation: US 2013/0247133 A1, "Security assessment of virtual machine environments," Michael Price & Anthony Bettini, assignee McAfee, Inc. Filed 2011-10-13 (App. 13/272,484); published 2013-09-19; granted US 8,850,512 B2 on 2014-09-30.
• Brief description: A security tool integrates with the virtual machine manager's APIs, enumerates each VM, determines online/offline status, then (i) for offline VMs, collects the machine image and assesses security from the collected images (reading image files, offline registry, and even simulating operation of the offline VM), and (ii) for online VMs, loads an agent. It generates per-VM result/report data with severity/priority indicators.
• § 102 mapping:
  • Claim 1 — API-based enumeration and location retrieval (b, c, d) ✓; image collection/analysis (e, f) ✓; reporting (h) ✓. Weak gap: the reference explicitly uses agents for online VMs (so "no interaction with the VM" is not universal to its disclosure), and it does not compute a numerical "risk level of the VM."
  • Claim 2 — "during the analysis … the virtual machine is inactive" is squarely met by the offline-image branch. Claim 14 likewise.
  • Claim 7/19 — "location … includes a virtual address of at least one of the virtual disks" is met by the VMM's status/location identification (IP/MAC/disk-location disclosure).
  • Strong § 102/103 art for claims 1–2, 4–8, 10, 13–14, 16–19; also used by Wiz as Exhibit 1018 in a related Orca IPR: https://www.docketalarm.com/cases/PTAB/IPR2025-00095/Wiz_Inc/docs/11-01-2024-Petitioner/Exhibit-1018-Price___US20130247133.pdf

2.3 US 2012/0323853 A1 / US 9,286,182 B2 (Fries, Hunt, Balakrishnan), Microsoft

• Full citation: US 2012/0323853 A1, "Virtual machine snapshotting and analysis," assignee Microsoft. Filed 2011-06-17 (App. 13/163,582); published 2012-12-20; granted US 9,286,182 B2 on 2016-03-15.
• Brief description: Automatically captures snapshots of running VMs, reads them to extract features (running guest OS, installed software, VM metadata), and performs automated (including ML) analysis on the feature pool to rank/flag VMs (e.g., likelihood of being "infected with a computer virus"). Snapshots may include a copy of the VM's memory (executing processes, kernel data structures).
• § 102 mapping:
  • Claim 1/13/22 — snapshot generation and automated analysis (e, f) ✓; claim 11 (detect a list of installed applications) is directly met ✓; claim 4/16 (VM active during analysis) ✓ because snapshots are taken while the VM runs.
  • Claim 9/21 — snapshots "repeatedly taken over time," "frequency of capturing" is expressly disclosed ✓.
  • Claim 10 — triggering on "conditions for capturing a snapshot (e.g., … high network saturation)" ✓.
  • Weak gap: does not recite cloud-platform API disk-location querying or sensitive-data / risk-level-of-the-VM prioritization.

3. Tier 2 — Secondary references (element-level § 102 art)

References cited in the '685 list that are NOT useful § 102 art for this patent's subject matter (they appear to be OR-of-classification noise or § 103 background): US 2017/0011138 A1 (Synopsys, "hierarchical power verification"); US 2017/0031704 A1 (HP, "network port profile"); US 2016/0364255 A1 (IBM, "VM template generation"); US 2018/0052762 A1 (Red Hat, "build failure management"); US 2018/0137032 A1 (Atlassian, "testing source code"); US 2013/0191643 A1 (Fujitsu, "chain of trust"); US 2014/0096135 A1 (IBM, "authenticated distribution of VM images"); US 2017/0052…/etc.

4. Full citation inventory (as printed in the patent's References Cited)

The document header states "Citations (47)." The rendered list in the supplied text shows 42 entries (the record appears truncated after US 10,782,952 B1). Below is the complete set that is actually present, with publication/filing priority dates:

(Note: entries #41–42 illustrate a recurring examination artifact — Orca's own co-pending family member US 2020/0244692 A1 appears in the citation list; it cannot be § 102 art against the '685 patent because it shares the same effective priority.)

5. Most-likely § 102 combination theory

If a challenger had to name the single-reference-of-record per limitation:

1. SecludIT US 2017/0111384 A1 → supplies the whole agentless architecture: cloud-API disk location → disk copy/clone ("snapshot") → analysis with no guest cooperation / no agent. Best § 102 shot at claim 13/22 (the "emulating the virtual disks … to generate a snapshot" limitation reads onto "clone or disk copy").
2. McAfee US 2013/0247133 A1 / US 8,850,512 B2 → supplies API-based VM enumeration, disk-location retrieval, offline image analysis (claims 2/14), and location-address limitation (claims 7/19).
3. Microsoft US 2012/0323853 A1 / US 9,286,182 B2 → supplies running-VM snapshotting + feature extraction of installed software (claim 11), scheduled/repeated snapshots (claims 9/21) and trigger-based capture (claim 10).
4. Amazon US 9,756,070 B1 → supplies machine-image scanning service + result containment/index and memory scanning (claims 1, 11).
5. The "risk level of the VM → filter/prioritize alerts" and "sensitive data" elements (claim 1(g)/(h), 5, 17) are the weakest-covered limitations across the cited list — closest partial support is Symantec US 9,069,983 B1 (sensitive info), Rapid7 US 2014/0137190 A1 (security levels), and ResponSight US 2018/0255080 A1 (threat ranking). Those two limitations are why the independent claims survived to grant.

6. Confidence, uncertainty, and cross-reference notes

• High confidence on every full citation, date, and abstract summary above that I re-verified by search (SecludIT, McAfee, Microsoft snapshotting, Amazon US 9,756,070 B1). The remaining entries are quoted directly from the "Citations" table in the patent's own front page as supplied.
• Explicit flag (consistent with the earlier section): the earlier-generated summary reports that IPR2024-00865 reached a Final Written Decision on 2025-12-08 holding all claims of the '685 patent unpatentable, and that the parallel Delaware suit (Orca v. Wiz, 1:23-cv-00758) was dismissed with prejudice (terminated 2026-01-13). That outcome is not reproduced in this section and does not conflict with it — but it materially changes the practical significance of the § 102 mapping above, since the claims' patentability has been adjudicated by the Board. I have no record of a Federal Circuit appeal for the '685 patent and will not assert one exists.
• Uncertainty: I do not have the specific ground-of-institution reference combination the PTAB used in IPR2024-00865 for the '685 patent. The exhibit numbering I found (SecludIT = Ex. 1097; McAfee = Ex. 1018) comes from related Wiz v. Orca IPRs, not the '685 record directly. Treat those as "likely but not confirmed" for the '685 IPR.
• Data-source caveat: the patent's front-page list is printed as "Citations (47)" but only 42 entries render in the supplied text (truncated after US 10,782,952 B1). I did not fabricate the missing 5; if the certified copy is needed, the USPTO PatentCenter file wrapper for App. 17/361,861 is authoritative.

Bottom line: For US 11,693,685, the single most relevant piece of prior art is SecludIT's US 2017/0111384 A1 (Loureiro/Donnat, pub. 2017-04-20) — it discloses the entire agentless cloud-API → disk-copy → vulnerability-analysis workflow that is the heart of claim 1/13/22. It is reinforced by McAfee US 8,850,512 (pub. 2013-09-19) for offline-image security assessment and location discovery, and by Microsoft US 9,286,182 (pub. 2012-12-20) for snapshot-content analysis of installed software. Combined, these three recitations collectively read onto essentially every limitation of claims 1–22, with risk-level-based alert prioritization and "sensitive data" detection being the only limitations lacking direct single-reference disclosure in the cited list.

I'll ground this analysis by checking the prior-art references and the PTAB record before writing the §103 analysis.

Let me pin down the specific grounds Wiz advanced against the '685 claims.

Obviousness Analysis — US 11,693,685 B2 under 35 U.S.C. § 103

Building on the prior sections: I will not re-state the bibliographic data, abstract, or claim summaries already produced. This section assumes them and focuses exclusively on the § 103 question. Two cross-reference flags before I begin:

1. Date discrepancy. The previously generated section states "Today's date is 2026-09-29"; this task prompt states "Current Date: April 26, 2026." I note the conflict rather than silently resolving it. Nothing in the analysis below turns on the difference, except that the February 9, 2026 CAFC appeal deadline has passed under either date and no appeal docket was previously found.
2. The single most important § 103 fact is already established: the PTAB's December 8, 2025 Final Written Decision in IPR2024-00865 held all claims 1–22 of the '685 patent unpatentable, and every ground Wiz asserted across the related IPRs was an obviousness ground. That is corroborated by the parties' D.I. 235 joint notice (https://archive.org/download/gov.uscourts.ded.83027/gov.uscourts.ded.83027.235.0.pdf) and by Orca's February 25, 2025 discovery request ("every Ground in these Proceedings is based on obviousness" — https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1556286](/patent/1556286)/download-documents?artifactId=rnILvBphtbONBD2aCTviJKRujdxGl-mnMu06LAD2hlau0SoL-y70M7Y).

0. Evidence base — and one important caveat about "the Prior Art section"

Caveat: The Google Patents page's "Citations (47)" table does not list the two references the Board actually relied on. The operative art in the IPR record is Veselov (U.S. Patent No. 11,216,563, Amazon, filed May 19, 2017) and Basavapatna (U.S. Patent No. 8,595,845) — neither of which appears among the 47 citations on the patent face. I therefore analyze two overlapping corpora:

• Corpus A — the 47 face-citations (the literal "Prior Art section" of the page): the ones most relevant here are US 2012/0323853 A1 → US 9,286,182 (Microsoft, VM snapshotting & analysis); US 2017/0111384 A1 (SecludIT/Loureiro, agentless virtual-server vulnerability detection via clone/disk copy); US 9,756,070 B1 (Amazon, scanning machine images); US 2013/0247133 A1 (McAfee, security assessment of VM environments — this is Wiz's "Price"); US 9,069,983 B1 (Symantec, protecting sensitive information in VM files); US 9,563,777 B2 (IBM, security policy from snapshots of similar VMs); US 2008/0263658 A1 and US 2009/0007100 A1 (Microsoft, offline scanning of VM images / suspending a running OS for scanning).
• Corpus B — the IPR references: Veselov, Basavapatna, Hufsmith (US 2020/0097662), Huseinovic ("Virtual Machine Memory Forensics"), Price.

Both corpora independently support the same conclusion. Corpus B is what the Board credited; Corpus A is what a reader restricted to the page's own citation list would use. I flag where I am extrapolating rather than quoting.

Verification of the key Corpus A references:

• US 2012/0323853 A1 (Microsoft), published Dec. 20, 2012, granted as US 9,286,182 on Mar. 15, 2016 — "automatically obtain snapshots of virtual machines as they are executing," read the snapshots "to obtain a set of features properties … including information about a running guest operating system, software installed on the virtual machine," analyze them, and "flag or rank snapshot according to weight of rules satisfied" (https://patents.google.com/patent/US20120323853 ; https://patents.justia.com/patent/[9286182](/patent/9286182)).
• US 2017/0111384 A1 (SecludIT / Loureiro), published Apr. 20, 2017 — agentless cloud vulnerability detection: the analysis system "connects to the virtual or cloud computer system," "uses an API, present in the system 1," requests cloning / "disk copy of the virtual production server," "analyzes the vulnerabilities of the clone or of the disk copy," and "a report analyzing the vulnerabilities … is generated" (https://www.freepatentsonline.com/y2017/0111384.html ; https://www.patents-review.com/a/20170111384-method-detecting-vulnerabilities-virtual-production-server.html). This is exceptionally on-point.
• US 9,756,070 B1 (Amazon), granted Sep. 5, 2017 — a "scanning service" that scans machine images, optionally launching an execution environment and performing memory scanning with "signature-based detection mechanisms, anomaly-based detection mechanisms," and selecting which scans to run "based on the content of the machine image" (https://insight.rpxcorp.com/patent/[US9756070B1](/patent/US9756070B1)).

Veselov quotes I have directly from the IPR record (quoted in Wiz's petitions as EX1007, full petition downloadable at https://www.docketalarm.com/cases/PTAB/IPR2024-00220/WIZ_Inc/docs/01-08-2024-Petitioner/Petition_as_filed-2-Petition__as_filed.pdf):

"The snapshot may include all of the data needed to recreate the state of the computing resource within a duplicate, virtual computing resource. For example, the target computing resource may be an instance of a virtual machine implemented within block-level storage device resources allocated to a logical volume. The snapshot may be a copy of the state of memory, the state of any devices (virtual or physical) allocated to the resource, block-level image of the entire logical volume…"

"At step 610, the scanning service may format the new logical volume into the corresponding file system and then mount the volume image in the logical volume as a read-only virtual hard disk… At step 614, the scanning service may perform the security assessment by reading the files of the mounted volume image… the scanning service may compare the names of directories and/or files in the image to character patterns representing known directory and/or filenames to identify 'signature' directories and files that identify the software application, version, installation attributes, etc." (Veselov 18:16–44)

"The present disclosure contemplates implementation of any suitable security assessment, including security assessments that are defined by rules packages, such as Common Vulnerabilities and Exposures (CVEs), Center for Internet Security (CIS) benchmarks, 'best practices' packages, static or runtime behavior analysis, host configuration assessments, and the like." (Veselov 2:35–41)

"comparing the assessment results to a remediation framework to identify one or more actions the user can take to address the vulnerabilities, and providing the identified actions to the user" (Veselov 10:17–36)

"trigger events that cause the assessment to begin" (Veselov 14:41–57)

1. Legal framework

Under Graham v. John Deere, obviousness turns on (1) the scope and content of the prior art, (2) the differences between the prior art and the claims, (3) the level of ordinary skill, and (4) objective indicia. Under KSR Int'l v. Teleflex, 550 U.S. 398 (2007), a claim is obvious where the prior-art elements were known, the combination is "a predictable use of prior art elements according to their established functions," or the combination is "obvious to try." Recognized rationales include: (a) combination of prior-art elements per known methods to yield predictable results; (b) simple substitution of one known element for another; (c) use of a known technique to improve a similar device in the same way; (d) application of a known technique to a known device ready for improvement; (e) "obvious to try"; (f) design incentives / market forces; and (g) teachings, suggestions, or motivations in the prior art.

The '685 claims carry no presumption-enhancing complexity: independent claim 1 is a system claim whose elements are each conventional data-processing steps (interface, API query, snapshot, analysis, prioritization, alert), and the specification describes them at a functional level without algorithmic detail.

2. Level of ordinary skill in the art ("POSA")

A reasonable formulation, consistent with the claim subject matter and the art:

A POSA would have a bachelor's degree in computer science, electrical engineering, or a related field, plus about 2–3 years of experience in cloud computing, virtualization, or cybersecurity; or, alternatively, comparable work experience. The POSA would be familiar with cloud provider control-plane APIs (e.g., AWS EC2, Azure, GCP), hypervisor-level snapshotting of virtual disks, vulnerability scanning and CVE databases, and risk-based alert triage. (Wiz's petitions used a comparable level; the Board did not disturb it.)

Nothing in the claims requires skill beyond this level. A POSA would have known how to call a cloud API to enumerate volumes, how to request a snapshot, and how to mount/parse that snapshot's filesystem offline.

3. Element-by-element mapping of independent claim 1

Claim 1 requires, at least: (a) establish an interface between a client environment and security components; (b) via that interface, use cloud platform APIs to identify virtual disks of a VM in the client environment; (c) use the APIs to query a location of at least one identified disk; (d) receive that location; (e) generate at least one snapshot of the disks; (f) analyze the snapshot to detect vulnerabilities and sensitive data, with no interaction with the VM; (g) determine a risk level of the VM; and (h) report… as alerts, the alerts being filtered and prioritized based on the determined risk level.

The only element for which Veselov is arguably silent on its face is express prioritization of alerts — which is exactly why Wiz paired it with Basavapatna. That pairing is the heart of Ground 1.

4. Ground 1 (primary): Veselov in view of Basavapatna

What Veselov teaches. Veselov is an Amazon patent on a cloud "scanning service" that takes a snapshot of a VM's backing logical volume, transforms/mounts it as a read-only virtual hard disk, and performs a security assessment by reading the files of that mounted image, matching directory/file names and package versions against CVE and CIS benchmark rule packages and host-configuration assessments, and then surfacing results and remediation actions. Every element (a)–(f) is met, and element (f)'s "no interaction with the virtual machine" is met because the assessment is performed out-of-band on the snapshot, with the production VM unaffected.

What Veselov does not expressly state. Veselov does not say its alerts are filtered and prioritized based on a determined VM risk level. It provides results and remediation actions, but not the risk-weighted, filtered alert stream required by element (h) and by "determine a risk level of the virtual machine" (g).

What Basavapatna supplies. Basavapatna (US 8,595,845) is a Symantec-era threat/risk-management patent that expressly computes per-asset risk metrics — a "threat-centric risk metric" and a "vulnerability-centric risk metric" — by combining asset configuration data, vulnerability definition data, and vulnerability detection data, using applicability data to distinguish assets that are genuinely exposed from those that merely have a vulnerable component installed. It then drives alerting and mitigation off those metrics and teaches active countermeasures ("eliminate, in whole or in part, the existence of the vulnerability," ¶21) and passive countermeasures (blocking attack traffic, ¶¶20–25, 28–29).

Mapping to (g) and (h): Basavapatna's asset-level risk metrics are a "risk level of the virtual machine," and its applicability-driven filtering is precisely "alerts … filtered and prioritized based on the determined risk level." Basavapatna also supplies the sensitive-data/configuration dimension for element (f′): its asset configuration data includes "configuration of the software running on the asset" and OS versions, and it assesses whether a given asset actually possesses the vulnerable configuration — i.e., checking configuration files of applications and operating systems, which is the '685 specification's own relevance-determination technique (see '685 ¶ discussing "check configuration files of the applications and operating system… if there is a vulnerable version or module not in use, the priority of that issue is reduced dramatically").

Motivation to combine (KSR rationales):

1. Same field, same problem, same actors. Both references address cloud/virtualized-asset security assessment and risk triage. Veselov identifies problems; Basavapatna prioritizes and mitigates them. Combining a detector with a well-known risk-prioritization/alerting layer is "a predictable use of prior art elements according to their established functions." KSR, 550 U.S. at 417.
2. Veselov itself points toward triage. Veselov describes producing assessment results and "comparing the assessment results to a remediation framework," and expressly contemplates a broad menu of assessments (CVEs, CIS benchmarks, best practices) that a POSA knows produces large volumes of findings. Alert overload was the well-recognized problem, so a POSA had a strong, articulated motivation to add risk-based filtering and priority ranking.
3. Design incentive / market forces. Enterprise security buyers demanded reduced false positives and prioritized remediation queues; the '685's own background acknowledges alert flooding as the driving concern ("This also reduces the number of alerts reported to the user"). That is objective evidence in the patent itself of the pre-existing motivation.
4. Predictable, no change in principle of operation. Bolting Basavapatna's risk engine onto Veselov's snapshot pipeline does not alter how either works: Veselov still reads the mounted image; Basavapatna still computes metrics from asset configuration + vulnerability definitions. The combination yields the expected result.

Dependent claims under Ground 1:

• Claim 2 (VM inactive during analysis; snapshot includes a memory page file): Veselov's snapshot "may be a copy of the state of memory," and Microsoft US 2009/0007100 A1 ("Suspending a Running Operating System to Enable Security Scanning") and Microsoft US 2008/0263658 A1 (offline scanning of VM images) supply the "inactive/offline" variant.
• Claim 3 (page file used to deduce running applications): Veselov's mounted-image reading plus the well-known VM-memory-forensics techniques of the day (Wiz cited Huseinovic, "Virtual Machine Memory Forensics," as EX1049). Reading process/memory state from a snapshot to infer executing processes was routine.
• Claim 4 (VM active during analysis): Microsoft US 2012/0323853 captures snapshots "while the virtual machine 114 is running"; and Veselov's snapshot of a live logical volume.
• Claim 5 (reporting includes priority levels): Basavapatna's risk metrics and ranking output.
• Claim 6 (remedial action): Basavapatna's active/passive countermeasures (patch, turn off vulnerable machine, block traffic) — the Board's construction of "remedial action" was "an action toward mitigating a detected threat or vulnerability."
• Claim 7 (location = virtual address of the disk): SecludIT discloses the owner providing the server identifier and the system resolving disks via the cloud API; Microsoft '853 discloses the "virtual machine image 140 … a specially formatted file (e.g., a VHD) on a file system."
• Claim 8 (snapshot includes a change log to restore to a point in time): The '685 specification's own discussion confirms this is the ordinary meaning of "snapshot" in this art; Microsoft '853 addresses snapshot/version/branch correlation information; EMC US 2020/0042707 A1 (snapshot-based detection/remediation, filed 2018) addresses the same.
• Claim 9 (multiple snapshots on a predetermined schedule): Microsoft '853 ("repeatedly evaluate time/conditions for snapshot generation"; "a defined range of time… may be used").
• Claim 10 (snapshot on a trigger event): Veselov's "trigger events that cause the assessment to begin" (14:41–57), which Veselov expressly contemplates for infrastructure changes.
• Claims 11–12 (installed applications and keys / non-secure configurations): Veselov 18:16–44 (identifying "software application, version, installation attributes"), and 2:35–41 (host-configuration assessments); Basavapatna (asset configuration data).

5. Ground 2 (Corpus A alternative): SecludIT + Microsoft US 9,286,182 + Amazon US 9,756,070

If one restricts the analysis strictly to references appearing in the page's "Citations (47)" table, the combination still renders claim 1 obvious.

SecludIT (US 2017/0111384 A1) is the closest single reference and was published Apr. 20, 2017 — more than a year before the '685's Jan. 28, 2019 effective filing date. It teaches, in express terms:

• an external "system for analyzing vulnerabilities" that is agentless and "uses an API" of the cloud system (element b);
• a request for cloning / a disk copy of the virtual production server and creation of that copy in the cloud system (elements c–e) — the functional equivalent of snapshotting the VM's virtual disk;
• analysis of the vulnerabilities of the clone or disk copy rather than the production server (element f), with no agent on the production server (the "no interaction with the virtual machine" requirement);
• the owner supplies the IP address and/or identifier of the server plus a key (elements c–d);
• detection of specific threat classes including "presence of non-integrated data, presence of logs, presence of intrusions… presence of changes in trend," which squarely reaches the '685's data-exposure findings (element f′);
• a report of the analysis (part of element h); and
• "security policies 8" that "allow the servers and the tests… to be classified according to how critical they are, the network and connection zone, and the threats," and which "define the depth and the frequency of the tests" — i.e., risk-tiered, prioritized handling (element g and the prioritization half of element h).

Microsoft US 2012/0323853 / US 9,286,182 adds automated snapshotting of running VMs, feature extraction from the snapshot revealing guest OS and installed software, and, critically, an analysis tool that can "flag or rank snapshot according to weight of rules satisfied" and "ranking of snapshots according to likelihood of a virtual machine having a defined condition (e.g., infected with a computer virus)" — that is prioritized alert output tied to a per-VM condition.

Amazon US 9,756,070 B1 adds a scanning service that scans machine images, optionally hosting an execution environment, performs memory scanning by signature- and anomaly-based mechanisms, and selects scans based on image content — reinforcing the "analyze without disturbing production" model and the content-driven detection of both vulnerabilities and sensitive content.

Motivation to combine (Ground 2):

• SecludIT, Microsoft, and Amazon are all in the same field (cloud/virtualized security scanning) and address the same documented problem the '685 background laments: agent-based scanning is cumbersome, network scanning is limited, and in-production intrusive tests are unacceptable. SecludIT says so expressly (performance/availability impact; "the owner does not have to provide the administrator key").
• Each reference relies on the same enabling technique set — cloud provider APIs + hypervisor clone/snapshot — so the POSA would reasonably expect to combine SecludIT's API + clone/disk-copy workflow with Microsoft's automated snapshotting-and-ranking and Amazon's managed scanning service, and to obtain the predictable result of a prioritized, agentless snapshot scanner.
• The rationale "use of a known technique (API-driven snapshot analysis) to improve a similar device (a cloud security scanner) in the same way" applies directly.

The only gap in Ground 2 is the express word "snapshot" in claim 1(e) and the "emulating the virtual disks" wording of claims 13/22. SecludIT's clone/disk copy and Microsoft's snapshot both satisfy this; note also that Orca itself argued before the Board that an "instantiated VM is not a 'snapshot'" and that "VM images and VM snapshots are not the same," while simultaneously arguing to the district court that a snapshot is simply "a copy of data" (per Wiz's D. Del. D.I. 202, at 13–14, https://www.docketalarm.com/cases/Delaware_District_Court/1--23-cv-00758/Orca_Security_Ltd._v._Wiz_Inc/202/). That inconsistency is an evidentiary problem for Orca on the snapshot/emulation limitation.

6. Ground 3: supplying "sensitive data" detection — add Symantec US 9,069,983 B1

Element (f) of claim 1 requires detecting both "vulnerabilities and sensitive data," and claim 13/22 do the same. Two Corpus A references fill that gap:

• Symantec US 9,069,983 B1, "Method and apparatus for protecting sensitive information from disclosure through virtual machines files" — on the face of the '685. This reference is directly about identifying sensitive information resident in virtual machine files — the very artifact the '685 analyzes.
• Amazon US 9,756,070 B1 "selects the scans to perform on a machine image based on the content of the machine image," and its scan-data model includes finding programs, services, ports, and content classes — a content-driven sensitive-data scan.
• McAfee US 2013/0247133 A1 (Wiz's "Price") teaches security assessment of virtual machine environments using disk/image analysis with scoring, providing a further route to per-asset risk.

Motivation: Detecting and alerting on unencrypted sensitive data, private keys, and cleartext credentials on a disk is a long-recognized, standalone security objective, and the '685 specification concedes as much (it lists "private keys found on the disks, system credentials stored clearly on the disk," PII search, etc.). Where a reference already teaches reading a VM's disk image to detect security problems, extending the same read to detect sensitive-data patterns is a "simple substitution of one known data class (vulnerability signatures) for another (sensitive-data patterns)" using the identical technical mechanism, with a predictable result. No new hardware, module, or architecture is required.

For the "sensitive-data ⇒ higher priority" preference (the '685 specification says such findings are "reported at a higher priority"): Basavapatna's asset-configuration/risk-metric machinery provides the prioritization substrate; feeding a "sensitive data present" signal into that risk engine is a routine weighting decision.

7. Dependent claims 14–21 (mirror of the earlier dependent set)

Claims 14–21 largely duplicate 2–10 in method/CRM form. The mapping in § 4 carries over verbatim: claim 14 ↔ claim 2 (Microsoft US 2009/0007100, offline scanning; Veselov memory state); claim 15 ↔ claim 3 (VM-memory forensics); claim 16 ↔ claim 4 (Microsoft '853 live snapshots); claim 17 ↔ claim 5 (Basavapatna ranking); claim 18 ↔ claim 6 (Basavapatna countermeasures); claim 19 ↔ claim 7 (SecludIT identifier/virtual address; Microsoft '853 VHD file); claim 20 ↔ claim 8 (change-log snapshot); claim 21 ↔ claim 9 (Microsoft '853 scheduled snapshot generation).

Note that claims 13 and 22 substitute "emulating the virtual disks of the virtual machine to generate at least one snapshot" for claim 1's "generate at least one snapshot." Veselov's step 610–614 — formatting the new logical volume, mounting the volume image as a read-only virtual hard disk, and reading files from the mounted image — is an express teaching of "emulating the virtual disks … to generate at least one snapshot," as is Microsoft '853's snapshot construction and SecludIT's clone/disk-copy. A POSA would read "emulating" as covering mounting/instantiating the disk image for read purposes; the '685 specification itself does not ascribe a special definition to "emulating," which weakens any narrow-construction argument (and parallels Orca's self-contradictory "snapshot" positions identified in D.I. 202).

8. Synthesis of motivation-to-combine (KSR categories applied)

9. The rebuttal side — why this matters, and what is NOT a strong defense

Orca's principal non-obviousness arguments (from IPR2024-00863, the sibling proceeding, https://ai-lab.exparte.com/case/ptab/IPR2024-00863/doc/38 and https://ptacts.uspto.gov/ptacts/public-informations/petitions/1556286/):

1. Objective indicia — competitor copying by Wiz; commercial success (Orca raised ~$6.5M by June 2019, ~$75M in 2020, ~$550M by 2021, valued $1.2–1.8B); industry praise; skepticism; the "SideScanning™" product embodying the claims.
2. No motivation to combine — Orca argued Wiz "mix[ed] and match[ed] embodiments in their Veselov-based contentions without a motivation to combine."
3. Claim-construction squeeze — Orca argued "analyzing the at least one snapshot" does not encompass "analyzing a VM instantiated from the snapshot," and that Veselov allegedly focuses on evaluating duplicate VMs.

Why these did not carry the day: the Board nonetheless issued a Final Written Decision on December 8, 2025 finding all claims of the '685 unpatentable (D.I. 235). Objective indicia must be coextensive with the claimed invention and attributable to the inventive features rather than to the general cloud-security market; Orca's own evidence (investor material describing "collect[ing] data directly from cloud provider APIs and the workload's runtime block storage out-of-band") tends to describe the claimed mechanism but also the prior-art mechanism, undermining nexus. Copying is probative but is a weak secondary consideration when the asserted copy also practices pre-existing API/snapshot techniques.

Two genuine vulnerabilities in the § 103 case that a careful analyst should note:

• "Sensitive data" nexus. None of the Veselov/Basavapatna excerpts I retrieved expressly recite detecting sensitive data on the snapshot; that element depends on the Symantec '983 combination (or an equivalent), and on the strength of the "substitution" rationale. If a finder of fact accepted a narrow reading of "sensitive data," claim 1's Ground 1 standing alone is incomplete.
• "No interaction with the virtual machine." Veselov is described in the record as, in one approach, "launch[ing] an active instance of the VM (which Veselov refers [to])" — i.e., some Veselov embodiments evaluate a duplicate VM. Orca's construction argument (analyzing a snapshot ≠ analyzing a VM instantiated from a snapshot) attacks that. The answer is that Veselov's Fig. 5A–B / Fig. 6 mounted-volume-image embodiments read the snapshot as a data file with no guest interaction — which is why Wiz was careful to anchor to those embodiments. This is the sharpest contested issue.

10. Confidence and open items

• High confidence: every element of claims 1, 13, and 22 was known in the art by the Jan. 28, 2019 effective filing date; the primary § 103 combination was Veselov + Basavapatna, with SecludIT (US 2017/0111384 A1) a strong single-reference "clone & scan" teaching from the page's own citation list; and the Board already found all '685 claims unpatentable on obviousness grounds on Dec. 8, 2025.
• Medium confidence: the precise ground-by-ground composition for '685 specifically (as opposed to the '735, '031, '032, '926, '326 siblings). I have the '685 institution decision (Paper 7, https://www.docketalarm.com/cases/Delaware_District_Court/1--23-cv-00758/Orca_Security_Ltd._v._Wiz_Inc/docs/218/3.pdf) confirming institution on claims 1–22 and referencing Veselov, and I have the D. Del. statement that Wiz's IPRs "included as a primary prior art reference … Veselov," but I did not retrieve the sealed '685 Final Written Decision itself. I therefore present Grounds 1–3 as the defensible § 103 case rather than as a verbatim recounting of the Board's '685 opinion.
• Unverified / flagged: the effective prior-art dates of Hufsmith (US 2020/0097662) and the Huseinovic NPL exhibit, since both post-date or lack a confirmed pre-2019 date in what I retrieved; any date argument on those two should be checked against the actual references.
• Not fabricating a CAFC outcome. Consistent with the previously generated section, I found no Federal Circuit docket for the '685 patent. The Feb. 9, 2026 appeal window has closed under the task's stated date; whether Orca filed is unknown, and the PTAB's unpatentability finding stands on this record.

Bottom line: The claims of US 11,693,685 would have been obvious under § 103 over Veselov in view of Basavapatna (the combination the Board credited across the Orca family), and independently over SecludIT (US 2017/0111384 A1) in view of Microsoft US 9,286,182 and Amazon US 9,756,070, with Symantec US 9,069,983 B1 supplying the sensitive-data limitation and McAfee US 2013/0247133 / Basavapatna supplying risk-based prioritization. Each claimed element was individually known, the combinations are predictable applications of known techniques in the same field, and the motivations to combine are explicit in the references and in the '685's own background. Consistent with that analysis, the PTAB held all 22 claims unpatentable on December 8, 2025.