US 6052780

I'll search for this specific patent number as instructed, then cross-check against the authoritative full text provided.

Let me run additional targeted searches for litigation and CAFC activity.

Let me try to retrieve the actual claim set, since the provided full text was truncated before the claims.

US Patent 6,052,780 — Summary

Note on sourcing: The full-text block you supplied (from Google Patents, fetched 2026-09-30) is authoritative and I've used it as the primary source. It is, however, truncated in the detailed-description before the claims section (it cuts off mid-sentence: "This other executable is the final digital info…"). My searches did not surface the literal claim text of US 6,052,780. The independent-claim overview below is therefore reconstructed from the patent's own Summary of the Invention (which enumerates the invention's aspects) and is flagged as inference, not verbatim claim language.

Bibliographic data (from the patent record)

Abstract (verbatim, as published)

"Some of these problems with digital information protection systems may be overcome by providing a mechanism which allows a content provider to encrypt digital information without requiring either a hardware or platform manufacturer or a content consumer to provide support for the specific form of corresponding decryption. This mechanism can be provided in a manner which allows the digital information to be copied easily for back-up purposes and to be transferred easily for distribution, but which should not permit copying of the digital information in decrypted form. In particular, the encrypted digital information is stored as an executable computer program which includes a decryption program that decrypts the encrypted information to provide the desired digital information, upon successful completion of an authorization procedure by the user. In combination with other mechanisms that track distribution, enforce royalty payments and control access to decryption keys, the present invention provides an improved method for identifying and detecting sources of unauthorized copies. Suitable authorization procedures also enable the digital information to be distributed for a limited number of uses and/or users, thus enabling per-use fees to be charged for the digital information."

Plain-language overview

The patent's core idea: instead of an external "helper" program or a hardware decryption standard, the protected content is itself packaged as an executable file that decrypts itself on the fly, so that decrypted code/data never lands in an accessible file. Two embodiments are described:

• Windows 95 embodiment (FIGS. 3–7): An unencrypted "unwrap procedure" stub runs first, locates an embedded "virtual device driver" and hidden encrypted content, dynamically loads the driver into the OS, and hands it (a) the location of hidden data in the file, (b) keys/passwords, and (c) a randomly generated "phantom directory"/file name. The stub then tells the OS to execute the file in the phantom directory. The loaded driver hooks between the OS and the file system driver, traps all calls aimed at the phantom directory, retrieves the corresponding bytes from the original file, decrypts/decompresses them, and returns cleartext to the OS on demand. Other calls pass through untouched.
• Windows NT 4.0 embodiment (FIG. 8): No device driver. The stub allocates locked protected memory (VirtualAlloc/VirtualLock), copies the encrypted DLL into it, decrypts in memory only, performs fix-up/relocation, sets the memory to execute-only (VirtualProtect), and executes the hidden code directly from memory — bypassing file system drivers and TSRs so they only ever see ciphertext. A variant uses CreateProcess/VirtualAllocEx/WriteProcessMemory to decrypt in one process and run in a second suspended process.
• FIG. 9 describes manufacturing the product: concatenating unwrap stub + optional driver + begin/end tags + encrypted/compressed hidden files into one .exe container.

Independent claims — inferred from the Summary (⚠ uncertainty flagged)

Because the claims themselves were not in the supplied text and my searches did not retrieve them, the following maps the patent's own enumerated "aspects," which typically correspond to the independent claims. Treat the numbering as unverified — I cannot confirm which independent claim numbers these are, or the total claim count.

1. Digital information product. A computer-readable medium storing digital information comprising computer program logic with (a) a first portion of executable computer program logic and (b) a second portion of digital information; the first portion, when executed, defines a mechanism that responds to requests for digital information from the computer's operating system; that mechanism accesses the second (encrypted) portion, decrypts it, and provides it to the operating system. (Note: the Summary literally says "provides the encrypted digital information to the operating system" — I'm reproducing that wording as written rather than correcting it.)

2. Computer program product. Same structure where the hidden content is encrypted computer program logic: the first executable portion responds to OS requests for program code, accesses the second encrypted portion, decrypts it, and supplies the decrypted program logic to the OS.

3. Self-decrypting encrypted executable program product (first/second/third modules). The first module, when executed, loads the second module into memory. The second module communicates with the OS to receive requests for program code from the third module (the encrypted executable program), accesses and decrypts that code in response, and provides the decrypted executable code to the OS.

4. Process for executing encrypted executable programs. On a system with processor, memory and OS: receive program logic comprising a first module (start-up routine), a second module, and a third module containing the encrypted executable program; execute the first module with the processor, thereby causing the second module to be loaded into memory; the second module receives OS requests for data from the encrypted program, accesses and decrypts it in response, and returns decrypted executable code to the OS.

5. Likely additional independent aspect — authoring/production. The Summary also recites "a computer program product, a computer system and a process which produce a computer program or digital information product… using executable program code for the first and second portions," which appears to correspond to the FIG. 9 combining method (open output file → insert unwrap procedure → insert driver tags/code → insert begin tag + encrypted/compressed hidden file + end tag → close).

CAFC 2026 docket search — result

I found no U.S. Court of Appeals for the Federal Circuit docket activity in 2026 involving US 6,052,780. Reporting explicitly:

• Multiple targeted searches ("6052780" with CAFC/2026, "6,052,780" with litigation/Open Security Solutions, US6052780 Federal Circuit appeal 2026) returned no matching 2026 Federal Circuit appeal. The only 2026 Federal Circuit material returned was an unrelated case (LifeCORE Fitness/Woodway treadmill claim-construction petition).
• Caveat / interpretive point: the patent record shows legal status "Expired – Lifetime" with anticipated expiration 2017-07-03. An expired patent generally cannot support forward-looking infringement relief, which is consistent with the absence of live 2026 appellate activity. However, I cannot exclude the possibility of a 2026 appeal involving past damages or a related family member — my searches simply did not surface one, and I have no authoritative database access to confirm a negative.
• The only litigation actually recorded on this patent's face is the Texas Eastern District Court case 2:08-cv-00316, plus a Darts-ip "first worldwide family litigation" flag.

Explicit uncertainties

• I could not verify the literal text or numbering of the claims of US 6,052,780; the supplied full text and my searches both lack the claims section. The independent-claim overview above is inferred from the Summary of the Invention.
• I could not confirm total claim count, dependency structure, or whether additional independent claims (e.g., apparatus/system claims, or the FIG. 9 production method) exist.
• I did not locate a 2026 USPTO or CAFC record; the absence of results is not proof of absence.
• The assignee chain shows an apparent intermediate entity (Digital Security Systems Corporation, LLC, assignor to RPX in 2011) that does not appear in the Google Patents "current assignee" trio — I flag this as a discrepancy in the record rather than resolving it.

I'll research litigation involving US 6,052,780 using the sources you specified.

Found a key lead. Let me dig deeper into the parties and cases.

Now let me find the outcome of that case and check for any other suits asserting this patent.

Litigation Involving U.S. Patent No. 6,052,780

Summary

Based on my searches of docket aggregators (Justia Dockets, PlainSite, Docket Alarm/Unified Patents data), a Law360 report republished by KIPO's international patent dispute board, and the litigation links on the patent's Google Patents page, one civil action asserting U.S. 6,052,780 is known. No Federal Circuit appeal of that action, and no other suit asserting this patent, was found.

Case 1 — Digital Security Systems Corporation, LLC v. Samsung Electronics Co., Ltd., et al.

Sources:

• https://dockets.justia.com/docket/texas/txedce/2:2008cv00316/[111413](/patent/111413)
• https://www.plainsite.org/dockets/k1y37bn1/texas-eastern-district-court/digital-security-systems-corporation-llc-v-samsung-electronics-co-ltd-et-al/
• https://www.kipo.go.kr/club/front/menu/bbs/view.do?clubId=dispute&menuId=3&curPage=1&messageId=15125 (reproduction of the Law360 article, Feb. 25, 2009: "Patent licensee Digital Security Systems Corp. has dropped its case against more than a dozen major electronics firms … without prejudice, allowing [refiling]")
• Google Patents litigation link for US6052780A: https://portal.unifiedpatents.com/litigation/Texas%20Eastern%20District%20Court/case/2%3A08-cv-00316
• https://patents.google.com/patent/US6052780/en ("Family has litigation" / "First worldwide family litigation filed," Darts-ip family 26700571)

Negative findings and limitations on this report

1. No other U.S. district court case asserting U.S. 6,052,780 was located. The Google Patents page for US6052780A lists only the single Eastern District of Texas case above, and the Darts-ip "first worldwide family litigation" entry points to the same family/matter. I did not find any additional suits (e.g., in the Central District of California, District of Delaware, or elsewhere) asserting this patent.
2. No appellate (CAFC) litigation found. Because the Texas case was dismissed without prejudice at the trial level, no appeal to the Federal Circuit arose from it.
3. No USPTO post-grant proceedings (IPR/PGR/CBM) for 6,052,780 were returned by my searches. I want to flag this as a negative result from my query set rather than a confirmed absence — I did not run a dedicated PTAB/Patent Trial and Appeal Board docket search, so I cannot state with certainty that no petition was ever filed against this patent.
4. Family members are separate patents. The patent's own family produced related U.S. patents (e.g., U.S. 6,185,686 and U.S. 6,868,495, per the Google Patents "Related" priority entries). Litigation asserting those patents is not litigation asserting 6,052,780, so I have excluded it. I did note one search hit referencing a CalAmp/"'278 patent" case (Omega Patents, LLC v. CalAmp Corp.); that is a different patent (Omega's '278 patent concerning vehicle telematics) and is not U.S. 6,052,780 — I am flagging it explicitly so it is not mistaken for this patent.
5. Status of the patent itself: 6,052,780 is recorded as Expired – Lifetime, with an anticipated expiration of July 3, 2017; it is currently shown as assigned to RPX Corporation, with Open Security Solutions LLC also listed. It therefore cannot be asserted in new infringement suits.
6. Provenance caveat: my information comes from public docket aggregators and a secondary news report, not from direct PACER access. Docket aggregator data can be incomplete (e.g., sealed documents, transfer/consolidation events). If a definitive record is needed, the case file for 2:08-cv-00316 should be pulled directly from PACER.

Bottom line: The only known litigation involving U.S. 6,052,780 is Digital Security Systems Corporation, LLC v. Samsung Electronics Co., Ltd., et al., No. 2:08-cv-00316 (E.D. Tex., filed Aug. 11, 2008), which was voluntarily dismissed without prejudice on February 23, 2009.

I'll verify the structured "no PTAB activity" signal against live sources before writing up.

The first hit discusses a "’780 patent" with an "internal firewall" limitation owned by Croga Innovations — that is not US 6,052,780. Let me dig specifically into the actual patent's owner history and any challenges.

No PTAB hits on the actual patent yet. Let me probe the litigation campaign and any IPR against the patent or its family members.

Proceedings overview

Zero AIA trial proceedings on file for US 6,052,780. The structured "PTAB proceedings on file" block (USPTO Open Data Portal) reports no IPR, PGR, or CBM for this patent, and my independent web searches surfaced none either. There are therefore no claims invalidated, none sustained, nothing settled, and no institution decision to report — the bottom-line defensive posture is unusual and worth stating precisely: this patent is not "hardened" by PTAB survivorship; it is simply uncontested and, critically, expired. Its 20-year term ran from the 1997-07-03 filing date and the structured data records "Anticipated expiration 2017-07-03" with legal status "Expired – Lifetime." A patent that expired roughly nine years ago will attract no IPRs and can support no prospective infringement claim.

Proceedings (none to enumerate)

The task template asks for one entry per proceeding, most-impactful first. There are no proceedings to enumerate. What follows is the verification trail instead, because the absence of PTAB activity is itself a dispositive fact for a defendant.

Negative search — US 6,052,780 — no petitioner

• Type: N/A (no petition filed)
• Filed: N/A
• Status: The structured block states, verbatim, that the USPTO ODP API returns no AIA trial proceedings for this patent as of the most recent ingest. Google Patents' family page lists litigation entries but no PTAB "Family has litigation" post-grant entries — https://patents.google.com/patent/US6052780/en
• Judge panel: N/A
• Petition grounds: N/A
• Institution decision: N/A
• Final Written Decision: N/A — no FWD exists, so no claim of this patent has ever been adjudicated unpatentable or patentable at the Board
• Settlement / termination: N/A
• Appeal: No PTAB FWD to appeal; consequently no CAFC appeal from a Board decision on this patent
• Defensive value: The absence of an IPR means there is no § 315(e)(2) estoppel against anyone, and every prior-art ground remains available to you. But it also means no one has needed to invalidate this patent administratively — most plausibly because it expired in 2017.

False-positive flag — a similarly numbered patent, not this one

My first search returned a PTAB petition discussing a "'780 patent" owned by Croga Innovations Ltd., challenged in IPR2024-01196 (Cisco Systems, Paper 7, 2025-02-13), IPR2025-00086 (Fortinet, Paper 9, 2025-03-27), and a third petition denied institution on Fintiv/discretionary grounds — https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1557759](/patent/1557759)/download-documents

This is a different patent. The asserted limitation there is an "internal firewall" implemented via "virtual machines" and "hypervisors" (Nazario reference), which has nothing to do with US 6,052,780's subject matter (a self-decrypting encrypted digital information product with an unwrap procedure and a hidden virtual device driver trapping phantom-directory calls). The Croga patent is also described as subject to an ex parte reexamination commenced August 2024 and as participating in ongoing district court litigation — none of which is corroborated anywhere in the US 6,052,780 record, which shows the patent expired in 2017. Do not cite the Croga proceedings, their denial reasoning, or their reexam as if they applied to your patent; conflating the two would be a sanctions-adjacent error. I could not retrieve the Croga patent's full number from the snippet (only the "'780" shorthand), so treat this as a caution flag rather than an identification.

Strategic summary

Claim status: fully UNTESTED. No AIA proceeding has ever construed or cancelled any claim of US 6,052,780. There are no "surviving claims" to point to in the IPR sense — there are simply untested ones, and the fetched full text of the specification was truncated before the claim set in my source, so I cannot map independent vs. dependent claims from the record I have. Do not represent to anyone that claims 1–5 (or any other numbered range) have been cancelled; that would be fabrication.

Estoppel landscape: entirely open, and moot anyway. Because no petitioner has ever filed against this patent, § 315(e)(2) estoppel attaches to no one, and no privies are barred from raising any § 102/§ 103 ground. For a defendant, that is unambiguously good — but the more powerful point is the expiration date. The structured data records the anticipated expiration as 2017-07-03 and legal status Expired – Lifetime. Prospective infringement of an expired patent is legally impossible; only past damages for pre-expiration acts within the § 286 six-year lookback remain theoretically reachable, and even that window has long since closed for most conduct.

Pattern signals. The only assertion activity in the record is a single Texas Eastern District Court case, docketed at 2:08-cv-00316 (https://portal.unifiedpatents.com/litigation/Texas%20Eastern%20District%20Court/case/2%3A08-cv-00316), plus a Darts-IP "first worldwide family litigation" entry. That suit predates the AIA's IPR regime (petitions were not available until 2012-09-16), which explains the absence of a parallel IPR at the time. What the record does not show is any later assertion campaign that would have provoked a post-2012 IPR. Ownership has since flowed inventor John J. Glover → Open Security Solutions, LLC (1999-12-10 bill of sale) → RPX Corporation (2011-01-28 assignment from Digital Security Systems Corporation, LLC). RPX is a defensive patent aggregator, which is consistent with the patent being parked rather than asserted — aggregators buy to neutralize, not to litigate. Notably, I found no Unified Patents filing against this patent; the "Unified Patents" reference in the structured data is only the source citation for the litigation dataset, not evidence of a Unified challenge.

Recommended next steps

• Lead with expiration, not invalidity. If you have received a demand letter citing US 6,052,780, verify the expiration date against the USPTO Patent Center record (https://patents.google.com/patent/US6052780/en shows "Anticipated expiration 2017-07-03," status "Expired – Lifetime") and check whether any term extension, continuation, or reissue could extend coverage. The family continuations — US 6,185,686 (priority 2000-04-07) and US 6,868,495 (priority 2000-07-21) — are the ones a sophisticated owner would assert if it wanted live coverage, so check whether the demand actually targets US 6,052,780 or a family member with a later expiry. That is the highest-value next check.
• No PTAB pathway is needed or available in practice. There is nothing to challenge at the Board, and even a hypothetical petition on an expired patent would be a poor use of resources. There is no institution deadline, no oral hearing date, and no statutory one-year FWD clock running, because there is no trial.
• Because no PTAB activity exists, say so plainly and treat the absence as informative. Well-asserted, unexpired patents in this technology space do attract IPRs — the parallel Croga example I flagged shows exactly that pattern for a different '780 patent. The fact that US 6,052,780 drew 2008-era litigation and then no post-AIA petition at all is consistent with a patent that had run out of commercial assertion life. If opposing counsel is asserting it today, ask directly for (a) the asserted claim numbers, (b) the accused acts and their dates, and (c) the term/expiry calculation — the answer will likely end the dispute.
• Verify independently before relying on this. My confirmation rests on the structured ODP block plus targeted web searches, and one search returned no results at all before I hit my tool-step limit. Before filing anything, pull the patent's full litigation and post-grant history directly from PTAB E2E / PTAB Decisions (https://ptacts.uspto.gov) and CourtListener (https://www.courtlistener.com) for the 2:08-cv-00316 docket, and confirm no recently filed proceeding has gone unindexed. Any proceeding I have not surfaced here would be newer than the ODP ingest; I found none, but I cannot prove a universal negative.

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

Let me dig deeper into the specific assignment records and litigation.

US 6052780 — Assignment Chain Reconstruction

Scope note up front (read before relying on any reel/frame below): I could reach the Google Patents legal‑events register for US 6052780 (embedded in the authoritative full text you supplied, fetched 2026‑09‑30) and a small number of third‑party mirrors. I could not obtain a working query against https://assignmentcenter.uspto.gov/ or https://assignment.uspto.gov/patent/index.html within this session. I therefore have no verified reel/frame numbers and no verified correspondent-of-record for any assignment on this patent. I have deliberately left those fields marked not verified rather than inventing them. One superficially similar RPX recording document did surface in search (reel 022955/0383, Digital Display Innovations → RPX Corporation, correspondent Berkeley Law & Technology Group LLP / Julianne Flynn, Beaverton OR) — that is a different patent family (U.S. 6,340,994 / 6,456,340) and is NOT a record for US 6052780. I flag it only as background on RPX's recording agent, not as a finding.

Inventors

Pattern notes:

• Contrary to the "all inventors out within 12 months" tell, the only inventor here did not depart the filing entity immediately. If Google's legal‑events date is the recording date, Glover's assignment of rights to Open Security Solutions, LLC was recorded 1999‑12‑10, roughly 27 months after the 1997‑07‑03 filing and 39 months after the 1996‑09‑12 priority date. That is an inventor‑to‑entity housekeeping assignment, not a rapid post-filing exit.
• There is a latent naming inconsistency worth flagging for a chain-of-title review: Google lists "Open Security Solutions LLC" as both the filer (1997‑07‑03) and the original assignee at grant, yet also records a "BILL OF SALE, ASSIGNMENT AND ASSUMPTION AGREEMENT" from GLOVER, JOHN J. to OPEN SECURITY SOLUTIONS, LLC in 1999. A bill of sale plus assumption agreement is asset-purchase language, which is a different instrument from a bare inventor assignment. Resolution requires the underlying recorded document.

Original assignee

OPEN SECURITY SOLUTIONS, LLC — named on the issued patent (granted 2000‑04‑18).

• Primary line of business: Not established from any source I could reach. The description of the patent's own field (self‑decrypting encrypted digital information products, DRM, DVD/CD‑ROM content protection) indicates an IP/security-technology venture rather than a mass‑market product company.
• Product embodying the claims: No evidence found of a shipped commercial product practicing the claims. No product literature, no SEC filing, no corporate site surfaced. Mark as unverified, no affirmative evidence of products.
• Current status: Appears defunct or otherwise inactive. Telling datapoint: the 2011‑01‑28 conveyance to RPX was recorded from a different named entity — "DIGITAL SECURITY SYSTEMS COPORATION, LLC" (spelled exactly that way in the Google record; the misspelling is likely a data-entry artifact, but note it as recorded). Either Open Security Solutions, LLC changed its name, or an intermediate transfer occurred that does not appear in the surfaced legal-events register. Check for a third, unindexed event between 2000 and 2011 — this is the single biggest gap in the chain.
• Term: Anticipated expiration 2017‑07‑03; legal status now Expired – Lifetime.

Assignment timeline

Important: execution dates below are the dates surfaced in the Google Patents legal-events register. For recorded assignments, Google typically surfaces the recording date; without the Assignment Center abstract I cannot separate execution date from recording date, nor supply reel/frame or correspondent.

• Execution date not verified / recorded 1999‑12‑10 — Reel not verified

  • Conveyance: Assignment (recorded as "BILL OF SALE, ASSIGNMENT AND ASSUMPTION AGREEMENT")
  • Assignor: GLOVER, JOHN J.
  • Assignee: OPEN SECURITY SOLUTIONS, LLC
  • Correspondent: not verified — could not retrieve from Assignment Center in this session.
  • Context: Inventor-to-entity title perfection roughly 27 months post-filing; asset-purchase form of instrument.

• Execution date not verified / recorded 2011‑01‑28 — Reel not verified

  • Conveyance: Assignment (recorded as "ASSIGNMENT OF ASSIGNORS INTEREST")
  • Assignor: DIGITAL SECURITY SYSTEMS COPORATION, LLC (as spelled in the record)
  • Assignee: RPX CORPORATION
  • Correspondent: not verified. (Adjacent RPX filings from the same era were recorded through Berkeley Law & Technology Group LLP, correspondent Julianne Flynn, Beaverton, Oregon — see reel 022955/0383 for a different family — but I cannot attribute that firm to this patent's record.)
  • Context: Defensive aggregation — transfer into an entity whose stated business is acquiring patent rights and licensing them to a subscriber network.

No other recorded assignments surfaced. Current-assignee field on Google Patents lists both RPX Corp and Open Security Solutions LLC, which is consistent with RPX holding title and the original entity remaining in the metadata.

Related family members (for chain-of-title completeness, not separate assignments):

• US 6,185,686 B1 — Ser. No. 09/545,065, priority 2000‑04‑07
• US 6,868,495 B1 — Ser. No. 09/621,187, priority 2000‑07‑21
• PCT/US1997/016223 → WO 1998/011690 A1; EP 0932955 A1; AU 42694/97; JP 2001‑521654

Timeline diagram

timeline
    title Ownership of US 6052780
    1996 : Provisional filed by John J Glover
    1997 : Utility application filed
    1999 : Glover assigns to Open Security Solutions LLC
    2000 : Patent issued
    2008 : Suit filed in Eastern District of Texas
    2011 : Digital Security Systems LLC assigns to RPX Corp
    2017 : Patent term expires

NPE / troll-pattern signals

1. Shell-entity transfer — unclear.
There is an LLC-suffix assignee (Open Security Solutions, LLC) but not an IP/Patents/Licensing/Holdings/Ventures suffix, and the transfer was from an individual inventor, not from an operating company divesting a product-line patent. No registered-agent address, no single-member Delaware/Texas confirmation, and no "no products in commerce" evidence were obtainable. The 2011 assignor rename to "Digital Security Systems … LLC" is consistent with a shell/rebrand pattern but naming alone is not a finding. Needs Assignment Center abstracts + state entity records.

2. Known asserter in the chain — not present (as to the listed asserters).
Neither Open Security Solutions, LLC nor Digital Security Systems … LLC nor RPX Corporation appears on the enumerated asserter list (Acacia, Marathon, IV, IPNav, Wi‑LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, Spangenberg entities). Note the directional subtlety: RPX is an anti‑NPE defensive aggregator, so its presence is evidence against, not for, an asserter characterization. I did not verify either LLC against the Unified Patents or RPX high-frequency-plaintiff directories.

3. Repeat correspondent across the chain — unclear / not assessable.
Correspondent of record was not retrievable for either of the two events, so recurrence cannot be tested. This is the signal the analysis most needs and the one I am least able to ground. Do not treat the Berkeley Law & Technology Group reference (Julianne Flynn, reel 022955/0383) as a match — it belongs to a different family.

4. Cascading transfers — not present.
Only two recorded links, dated 1999‑12‑10 and 2011‑01‑28 — approximately 11 years apart. No chained LLC hops within 24 months, no shared correspondent address demonstrable, no common principals demonstrable.

5. Pre-litigation transfer — not present on available dates.
A case was filed in the Eastern District of Texas (2:08‑cv‑00316, 2008). Neither recorded assignment falls in the 6‑month window before 2008: the 1999‑12‑10 record predates it by ~8 years, and the 2011‑01‑28 record postdates it by ~3 years. Caveat: I could not confirm the exact filing date or the plaintiff in 2:08‑cv‑00316, so the second half of this call rests on the 2008 vintage of the case number.

6. Bankruptcy fire-sale — not present.
No Chapter 7/11 proceeding, no stalking-horse sale, no court-approved sale order surfaced for Open Security Solutions, LLC or Digital Security Systems … LLC.

7. Privateering — not present.
No SEC filing, no Patent Progress / EFF coverage, and no evidence of an operating company funding assertion against competitors. Note the 2011 transfer runs toward a defensive aggregator, which is the opposite direction from privateering.

8. Defensive aggregator — present.
Chain terminates at RPX CORPORATION, on the 2011‑01‑28 recorded assignment from Digital Security Systems … LLC, and RPX remains the listed current assignee. RPX is named expressly in the signal list as a defensive aggregator. Independent corroboration of RPX's defensive-aggregation model and its recording practice exists in the public record (RPX Form S‑1 and annual reports, as discussed in the Westlaw-indexed commentary surfaced in search), and in the analogous RPX recording at reel 022955/0383. Inverse signal: this patent has been neutralized.

Verdict

Defensive / non-asserting.

The chain terminates at RPX Corporation via the assignment recorded 2011‑01‑28 from DIGITAL SECURITY SYSTEMS COPORATION, LLC, and RPX remains the listed current assignee — RPX being the defensive aggregator named in signal 8, whose documented model (RPX Form S‑1 / annual reports) is acquiring patent rights to license them across a subscriber network rather than to assert them. The only other recorded link, GLOVER, JOHN J. → OPEN SECURITY SOLUTIONS, LLC, recorded 1999‑12‑10, is an inventor-to-entity filing, and no asserter on the enumerated NPE list appears anywhere in the chain. The single caveat is the E.D. Tex. 2:08‑cv‑00316 case (2008), whose plaintiff I could not confirm; if that suit was brought by the pre‑RPX owner, the pre‑2011 history would need re-characterizing, but the terminal ownership fact is unchanged.

Confidence limitation: this verdict rests on (a) the Google Patents legal-events register and (b) the RPX terminal assignee. It does not rest on reel/frame or correspondent data, which I could not retrieve. Before filing this as a formal conclusion, pull the two Assignment Center abstracts to fill in reel/frame, execution dates, and correspondent — and specifically hunt for an unindexed event between 2000 and 2011 that explains the Open Security Solutions, LLC → Digital Security Systems … LLC name change.

Verify at: https://assignmentcenter.uspto.gov/ (search by patent number 6052780) and the mirrored index at https://assignment.uspto.gov/patent/index.html

I'll search for the patent and its cited references.

Let me get the specific citation list from the patent record.

I have the citation list. Let me verify details on the most §102-relevant references.

1. Confirming the target document

I searched for the literal identifier 6052780 and located the corresponding U.S. grant:

Source: https://patents.google.com/patent/US6052780/en and http://www.everypatent.com/comp/pat6052780.html

Identifier caution (no auto-correction applied): a web search for "6052780" also returns JP 6052780 B2 (2016-12-27, "アルミナ水和物微粒子粉末の製造方法…" — a Japanese patent on alumina hydrate fine particles). That is a different, unrelated document and is excluded from everything below. Likewise, an EPO abstract page renders the family as "US6185688B1," which is not the identity of US6052780; I flag it rather than reconcile it.

2. Source and caveat on the citation list

The list below is the "References Cited" material printed on the face of US 6,052,780 as reproduced at EveryPatent (http://www.everypatent.com/comp/pat6052780.html). I was able to corroborate the patent's identity and the examiner/classification data, but I could not retrieve the USPTO Patent Full-Text (PatentCenter) "References Cited" pane directly within my tool budget, so the list is taken from that mirror of the printed patent. Treat the bibliographic fields as accurate to the printed patent; treat my characterizations of individual references as analytical (below) rather than as quotations from the file wrapper.

Important framing: the references below are the references cited on the patent. In the 6,052,780 specification most of them are cited as background art in two large boilerplate passages ("some mechanisms restrict the use of digital information to a particular machine… / Other mechanisms require… a particular recording medium… / Yet other mechanisms allow only a certain number of uses…" and the long "several other patents describe a variety of systems for encryption, compression, licensing and royalty control and software distribution such as: …" list). Citation on the face of a patent is not evidence of an anticipation rejection. My § 102 column is therefore an anticipation-potential assessment, not a record of what the examiner actually rejected.

The claims at issue (as printed) are claims 1–8+ :

• Claim 1 — process: OS reads/loads/executes first code as a first process having a protected memory area; the first process authorizes decryption, decrypts encrypted code into second executable code stored in the protected memory area; and the first process causes loading and execution of the second code in the protected memory area.
• Claim 2 — first + encrypted code in a single file.
• Claim 3 / 6 — execution as a second process with a second protected memory area.
• Claim 4 — computer program product counterpart of claim 1.
• Claim 5 — single data file.
• Claim 7 — computer system whose OS has a command creating a first process in response to a process identifier + a memory location holding executable code.
• Claim 8 — computer system: means for storing encrypted code in a file that also includes first executable code (text truncated in the mirror; the claim set continues beyond claim 8).

3. Cited U.S. Patent Documents

4. Cited foreign patent documents

Note: the WO 1997–1999 items post-date both the Sept. 12, 1996 priority date and the July 3, 1997 filing date of US 6,052,780. Strictly, such later-published documents can only be § 102(e)/§ 102(a)-type art if they have an earlier effective filing date, or they function as background/specification-incorporated material rather than anticipating art. I flag this rather than assume.

5. Cited non-patent literature (printed on the face)

• InterTrust Technologies Corp., "Technology Overview," 12/24/96, pp. 1–2.
• Olin Sibert et al., "Securing the Content, Not the Wire, for Information Commerce," 12/24/96, pp. 1–12 (InterTrust).
• Lloyd Chrein, "Products Right Copyright Wrongs," 12/18/96, pp. 1–4.
• Global Village Publishing, Inc., "Folio Publisher 4.0," 12/24/96, pp. 1–6.
• Publication Rights Clearinghouse, "National Writers Union and the UnCover Company Create Copyright Model for Electronic Database Industry," 12/26/96, p. 1.
• Patel, Tara, "International Firms Press for Encryption Software Pact," Tribune Business News, 1/30/96, pp. 1–2.
• Cryptolope Containers, "Welcome to the Cryptolope Showcase," 10/23/96, pp. 1–9.
• Philip E. Rose, "Cops Versus Robbers in Cyberspace," Forbes, 9/9/96, pp. 134–139.
• Damon Darlin, "Intel's Palace," Forbes, 9/9/96, pp. 42–43.
• Lisa Gubernick, "I Didn't Want to be a Digit Head," Forbes, 9/9/96, pp. 80, 84.
• "A Place to Chat," Forbes, 9/9/96, pp. 168, 170–171.
• Business Wire, "Zoran Receives DVD Copy Protection Software License From CSS…," 6/3/97, pp. 1–2.
• J. Scott Carr, "Digimarc Watermarking Technology Receives U.S. Patent," Business, 6/11/97, pp. 1–2.
• Wilson, David, "San Jose, Calif., Start-Up Could Put Music Retail Business OnLine," San Jose Mercury News, 6/16/97, pp. 1–6.
• Carey Nachenberg, "Computer Virus–Antivirus Coevolution," Communications of the ACM, Vol. 40, No. 1 (Jan. 1997), pp. 46–51 — the polymorphic/encrypted-virus decryption-program art discussed in the 6,052,780 background section.
• Wilson, David, "Startup's Product May Prevent Piracy," San Jose Mercury News, 6/15/97.
• Jacobs, R., "Tequila — A Cocktail of Viral Tricks," Virus Bulletin, June 1991, pp. 16–17.
• Skulason, F., "Virus Encryption Techniques," Virus Bulletin, Nov. 1990, pp. 13–16.
• Messmer, Ellen, "Satan Bug Virus on the Loose in Government Computers," Network World, 10/11/93, p. 25.
• Daly, James, "The Newest Virus Threat," ComputerWorld, 8/17/92, p. 37.
• Konigs, H.-P., "Cryptographic Identification Methods for Smart Cards in the Process of Standardization," IEEE Communications Magazine, Vol. 29, No. 6, June 1991, pp. 42–48.
• "Data Masking Algorithm," IBM Technical Disclosure Bulletin, Vol. 32, No. 6B, Nov. 1989.
• "Information Distribution via ROM Disks," IBM Technical Disclosure Bulletin, Vol. 33, No. 12, May 1991.

The virus-related items (Nachenberg, Jacobs, Skulason, Messmer, Daly) map to the specification's discussion of self-decrypting encrypted viruses — the closest structural analogue to a self-decrypting executable, and thus the most plausible § 102 backdrop for claim 1's "decrypt itself as it executes" concept, though a virus lacks the claimed protected-memory/authorization features.

6. Bottom-line § 102 assessment

Strongest potential anticipatory candidates (single-reference, claims 1 and 4):

1. US 5,509,074 — Choudhury et al. (AT&T), filed Jan. 27, 1994, issued Apr. 16, 1996. Discloses publisher-side encryption/compression and recipient-side agents that decrypt and uncompress only in response to the correct secret key supplied by an authenticated requesting user, with agents pre-installed or delivered at time of use, and with the option of decryption in the recipient computer's software. This is the closest cited reference to the "authenticated, on-demand, in-place decryption without exposing plaintext to the user" concept that animates claims 1/4. Its weak point for strict anticipation is that it does not clearly teach decrypting executable code into a protected memory area and then causing the operating system to load and execute that code from that protected area (claims 1, 3, 6).
2. US 5,563,946 and US 5,598,470 — Cooper et al. (IBM), issued Oct. 15, 1996 and Jan. 28, 1997. Cited by the applicant itself as the Cryptolope secure-container art. These bear on claim 4's "computer program product" structure (encrypted content packaged with a decrypting/helper executable) and on claim 1's decryption-upon-authorization step.
3. EP 0 679 977 / 0 679 978 / 0 679 979 / 0 681 233 (Nov. 1995) — the European Cryptolope-family publications, same subject matter as item 2.
4. US 5,490,216 — Richardson, III (Feb. 1996) and US 4,888,798 — Earnest (Dec. 1989): address per-use/limited-use authorization (claim 1's authorization step).
5. US 4,817,140 — Chandra et al. and US 5,412,718 — Narasimhalu et al.: machine-binding and media-binding use restriction (claim 1's authorization step).

Weak/likely non-anticipatory: the bulk of the 1978–1995 software-copy-protection patents (4,120,030; 4,168,396; 4,262,329; 4,278,837; 4,306,289; 4,319,079; 4,433,207; 4,465,901; 4,847,902; 5,081,675; etc.) are cited in the "several other patents describe a variety of systems…" background paragraph and, on their face, disclose dongle/key-disk/media-binding or license-management mechanisms rather than the claim 1 sequence (protected memory area → in-memory decryption of executable code → OS loads/executes the decrypted code from that protected area). They are § 103 fodder far more than § 102 art.

Explicit uncertainties I will not paper over:

• I could not confirm the examiner's actual rejections or the file-wrapper "cited by examiner vs. cited by applicant" breakdown from the USPTO full-text system within my tool budget.
• For roughly a third of the listed U.S. patents I can confirm the bibliographic data (number, date, inventor, class) from the printed patent but do not have high-confidence knowledge of their specific disclosures; the "brief description" and § 102 column for those rows are inferences from their technology area and should be verified against the documents themselves before being relied on.
• The single reference that most nearly meets claim 1 as a whole is US 5,509,074, but on the material I have it does not expressly disclose the "protected memory area" and "load/execute decrypted executable code from that area" limitations, so a § 102 anticipation of claim 1 is not established by that reference alone.

If you want, I can next pull the full text of 5,509,074, 5,563,946 and 5,598,470 and do an element-by-element (claim-chart style) comparison against claims 1–8 of US 6,052,780.

I'll ground this analysis in the actual references cited in the patent's Background ("Prior Art") section. Let me verify what the key references disclose before building the § 103 combinations.

Let me verify titles/scope for additional cited references I want to rely on.

Obviousness Analysis — U.S. Patent No. 6,052,780

"Computer System and Process for Accessing an Encrypted and Self-Decrypting Digital Information Product While Restricting Access to Decrypted Digital Information"

0. Two threshold caveats (please read before relying on this)

0.1 The claim text was not included in the material provided. The authoritative patent text supplied to me is truncated mid-sentence in the Detailed Description ("...This other executable is the final digital info"), and the "Claims" section is absent. I therefore analyze the inventive aspects as they are actually enumerated in the patent's own Summary of the Invention, which correspond to what the issued claims recite. Where I use a shorthand like "Claim 1," it denotes the first enumerated aspect, not verified claim language. A final, litigation-grade § 103 analysis must be re-run against the literal claim text and the file history.

0.2 Date/qualification audit. Priority date of record is 1996-09-12 (provisional 60/025,991; non-provisional 08/887,723 filed 1997-07-03). This is a pre-AIA case, so the § 102(b) critical date is 1995-09-12, and § 102(e) art (U.S. patents/application publications, by US filing date) is available for § 103.

The Nachenberg date problem is real and I flag it explicitly below (Section 5).

1. The invention, reduced to its constraining elements

Stripped of implementation detail, the enumerated aspects require:

• (A) A single distributable product on a computer-readable medium containing both unencrypted executable logic and encrypted digital information/program code.
• (B) The unencrypted logic, when executed, responds to requests issued by the operating system (not by a user typing commands) for the digital information.
• (C) It accesses, decrypts, and returns the decrypted information to the operating system — i.e., the OS believes it received ordinary data from a file, whereas the bytes actually came from an encrypted region of the product.
• (D) (Embodiment 1) The decrypting entity is a dynamically loaded device driver/VxD hooked between the OS and the file system driver, invoked via a "phantom directory" whose name only the unwrap procedure and the driver know, with per-segment file names.
• (E) (Embodiment 2) The decrypting entity is the stub executable itself, which allocates protected memory (VirtualAlloc), decrypts into it, locks it (VirtualLock), fixes up relocations, and makes it execute-only (VirtualProtect), so the OS loads code from memory, bypassing the file-system-driver path.
• (F) Authorization/per-use/per-machine gating, keys, hardware identifiers, networks, DVD/audio/video content.
• (G) A production process (FIG. 9): concatenate unwrap procedure + begin/end tags + encrypted hidden files into one executable.

Elements (A)–(C) are the heart of every independent aspect. (D), (E), (F), (G) are the differentiators, and they are also where the prior art is thickest.

2. The prior art the patent itself puts on the table

The patent's Background is unusually self-damaging. It affirmatively admits:

1. The CRYPTOLOPE container, tied to U.S. 5,563,946 and 5,598,470 (Cooper et al.) and EP 0679977/0679978/0679979/0681233, in which "[t]he helper application is a form of memory resident program, called a terminate and stay resident (TSR) program, which is a form of input/output (I/O) device driver installed in the operating system and which monitors requests from the operating system for files on specified drives and directories."
2. That the container "includes an executable stub which is executed whenever the application is run without the installed TSR program or from a drive not monitored by the TSR program," and that this stub "may be used to install decryption and cause the application be executed a second time."
3. That self-decrypting, encrypted, executable code was well known in the virus art — "the virus includes a decryption program that executes to decrypt the virus every time the infected program is run," citing Nachenberg.
4. That copy protection via per-machine binding, per-medium binding, and use-counting was known (U.S. 4,817,140; 5,412,718; 4,888,798).
5. That a unified DVD encryption format (CSS) and its licensing organization existed.
6. That Windows 95 permits a device driver to be loaded dynamically "without restarting the computer," and it quotes the Microsoft Visual C++ Help documentation for CreateProcess, LoadLibrary, LoadLibraryEx, CreateFile, MapViewOfFile, MapViewOfFileEx, and CreateNamedPipe — i.e., the OS primitives on which the invention is built are admitted, documented prior art.
7. That debuggers (SoftIce from NuMega, WinDebug from Microsoft, CodeView) already implement "a first process that controls execution of a program to be debugged as a second process," and that this modified-debugger pattern is the analogue of the invention.

Under § 103 these are admissions about the content of the prior art and about the level of ordinary skill, and they neutralize any argument that the inventor was the first to conceive of "encrypted program code that decrypts itself on demand."

3. Mapping the elements to the art

I verified the following directly:

• Cooper '946: IBM, "Method and apparatus for enabling trial period use of software products: method and apparatus for passing encrypted files between data processing systems," filed 1994-04-25, issued 1996-10-08, inventors Thomas E. Cooper et al. (https://patents.google.com/patent/[US5563946](/patent/US5563946)) — discloses a file management program supplied as an operating-system component that monitors/intercepts data-processing system calls for a called file, determines whether the called file bears a decryption block, and "dynamically decrypt[s] [the file] as it is passed to the operating system for processing." It further discloses an unencrypted executable "security stub" at least partially composed of executable code attached to the encrypted file, examined before the file is allowed to proceed.
• Cooper '470 (https://companyprofiles.justatic.com/patent/5598470) — the companion patent, disclosing a TSR that "intercepts and handles DOS file input and output operations," and, critically, the assembly procedure: "(1) the application is encrypted; (2) a decryption block is created for this program; (3) a pre-built executable stub is attached to the front end of the decryption block; (4) the length of the combined decryption header and executable stub is determined; (5) the bytes at the front of the executable file equal to this length are then read into memory...; and (6) the encryption header and executable stub are then written over the leading bytes in the executable code." The '470 stub "can duplicate the functionality of the TSR and install dynamic encryption before kicking off the application a second time," "turn on a temporary access key," or "communicate with the TSR and inform it to look at the drive the application is being run from."
• Nachenberg 1997 (https://dlnext.acm.org/doi/epdf/10.1145/[242857](/patent/242857).[242869](/patent/242869)) — "When a program infected with a polymorphic virus is launched by the user, the polymorphic decryption routine executes and decrypts this unchanging virus body... Thus, when a file containing a polymorphic virus is executed, the virus is guaranteed to decrypt itself... the virus does all the decryption work."
• Cryptolope (CNET, https://www.cnet.com/tech/tech-industry/hackers-cant-interlope-a-cryptolope/; NASA TM-2001-211426, https://www.cs.odu.edu/~mln/pubs/NASA-2001-tm211426.pdf) — a container holding encrypted content + clear metadata + authentication materials, per-content-block keys encrypted under a master key, delivered by a helper application plug-in, with key release by a clearinghouse and post-decryption watermarking/fingerprinting.

The residual delta between the prior art and the independent aspects is therefore narrow and consists mostly of:
(i) the decrypting logic being part of the distributed product rather than a pre-installed resident program; and
(ii) the implementation choice of a hooked VxD (embodiment 1) or memory-resident protected code (embodiment 2) as the interception/decryption locus, with a randomly named "phantom directory" as the rendezvous point.

4. Combinations that render the claims obvious

Combination 1 — Cooper '946/'470 in view of the self-decrypting-executable art (Nachenberg / admitted virus art)

Proposed: Cooper '946 + Cooper '470, further in view of the self-decrypting encrypted executable known in the virus literature (Nachenberg, and the patent's own Background admission thereof).

Why the combination is complete:

• Cooper supplies (A), (B), (C) almost verbatim: an OS component that intercepts OS file calls, recognizes an encrypted/decryption-block file, decrypts, and passes plaintext to the OS. Cooper even supplies the "stub embedded in the product" idea (element (i) above) in the '470 stub that "duplicate[s] the functionality of the TSR and install[s] dynamic encryption."
• The virus art supplies the second, necessary teaching: that the decryption logic can be carried inside the encrypted file itself as executable code that decrypts the file body on execution. This is precisely element (i).
• The only thing Cooper does not show is the phantom directory random-name rendezvous and the VxD hook (element (ii)).

Motivation, stated in the art and in the patent's own words:

1. The patent itself states the motivation to leave Cooper/Cryptolope: "Because the TSR program must know the directory, and/or file name to be accessed, that information also is also available to other programs. Other programs could use that information to manipulate the operation of the TSR program in order to have access to decrypted contents of the information container." The claimed random phantom-directory name is the predictable, conventional fix for exactly that admitted weakness — obscurity of the rendezvous name. KSR: "a predictable variation... a product not of innovation but of ordinary skill and common sense."
2. The patent itself states the motivation to leave the third-party helper model: "It may be preferable from the point of view of the content provider however to maintain an encryption process and keys independently of any third party." Cooper's and Cryptolope's helper/clearinghouse architecture is third-party-mediated; making the container self-decrypting is the direct response.
3. Cooper '470 already teaches a stub that installs dynamic encryption and re-launches the application — so the step of "self-installing decryption" is taught, and combining it with a self-decrypting encrypted body is a mere substitution of known equivalents (TSR-mediated decryption ⇄ in-product decryption), with no new result beyond the predictable one.
4. Windows 95 dynamically loadable VxDs, IFS hooking, and DeviceIOControl (named in the patent) are admitted, documented OS facilities. Selecting that facility over a DOS TSR is engineering choice among known options.

Conclusion: Claims 1, 2 and the process/product aspects would have been obvious over Cooper '946 in view of Cooper '470 and the admitted self-decrypting-executable art. This is the strongest single combination and would also support a § 102(e) anticipation argument as to the broader aspects (Cooper '470 alone discloses encrypted file + embedded executable stub + dynamic decryption to the OS).

Combination 2 — Cooper + Cryptolope + the content-provider-control art

Proposed: Cooper '946/'470 in view of the Cryptolope container architecture (including EP 0679977/0679978/0679979/0681233) and the software-distribution/licensing/royalty patents (U.S. 4,405,829; 4,864,616; 4,888,800; 4,999,806; 5,021,997; 5,027,396; 5,033,084; 5,081,675; 5,155,847; 5,166,886; 5,191,611; 5,220,606; 5,222,133; 5,272,755; 5,287,407; 5,313,521; 5,325,433; 5,327,563; 5,337,357; 5,351,293; 5,341,429; 5,351,297; 5,361,359; 5,379,433; 5,392,351; 5,394,469; 5,414,850; 5,473,687; 5,490,216; 5,497,423; 5,509,074; 5,511,123; 5,524,072; 5,532,920; 5,555,304; 5,557,346; 5,557,765; 5,592,549; 5,615,264; 5,625,692; 5,638,445).

This combination lands elements (F) — authorization, per-use/per-user fees, royalty tracking, hardware identifiers, network/CD-ROM/DVD distribution. The patent's Background concedes this entire body of art is directed to "encryption, compression, licensing and royalty control and software distribution." Cryptolope contributes the container + per-block keys + clearinghouse + post-decryption watermarking/fingerprinting, i.e., the "identification and detection of unauthorized copies" that the patent's ABSTRACT claims as an improvement. Because all references are in the same field and address the same problem (protecting distributed digital content while enabling trial/limited use), the motivation to combine is the problem itself — KSR (a known problem, and the references' own express purposes).

Combination 3 — The FIG. 8 aspect (protected-memory decryption; OS loads code from memory)

Proposed: Cooper '946/'470 in view of the documented Win32 API (admitted prior art: VirtualAlloc, VirtualLock, VirtualProtect, CreateProcess, LoadLibraryEx, MapViewOfFileEx, VirtualAllocEx, WriteProcessMemory) and in view of the debugger art the patent itself names (SoftIce, WinDebug, CodeView — a first process controlling a second process's execution).

• The claim elements (E) are literally the standard Win32 protected-memory idiom applied to decryption: reserve/commit, decrypt in place, lock, relocate/fix up, mark execute-only. Every one of those calls is quoted by the patent from Microsoft's own documentation.
• The motivation is stated in the patent itself: the FSD-hooking embodiment (D) has a known weakness — "another file system driver can hook into the operating system to monitor traffic between the operating system and all file system drivers and capture decrypted executable code." Eliminating the FSD path by decrypting into memory is the obvious alternative, and the two-process/suspended-process variant is the admitted debugger pattern.
• Predictable result, documented primitives, same field. Obvious under KSR.

Combination 4 — The FIG. 9 production-process aspect

Proposed: Cooper '470 alone, or Cooper '470 in view of the tag/structure conventions of the container art.

Cooper '470 recites the identical production method: encrypt the file, form a decryption header, attach a pre-built executable stub to the front end, determine the combined length, side-file the displaced leading bytes, and overlay header+stub — yielding a single self-contained file. That is FIG. 9's "insert unwrap procedure; insert begin tag; insert encrypted hidden file; insert end tag; close file." Using named begin/end markers or a location table to delimit segments is a conventional data-format choice.

5. Is the Nachenberg reference usable? (Candid risk assessment)

Publication of Nachenberg (Jan. 1997) postdates the 1996-09-12 priority date. It is therefore not § 102(b) art, and is § 102(a) art only if the applicant's actual invention date is later than January 1997 — unlikely. Two consequences:

1. Do not build the § 103 case on Nachenberg as an invalidating reference alone. Build it on (a) Cooper '946/'470 as § 102(e) art, and (b) the patent's own Background admissions about self-decrypting encrypted viruses, which are admissible regardless of Nachenberg's date and which independently establish that the self-decrypting-executable concept was known. If Nachenberg is needed at all, use it as corroboration of the state of the art, not as the anticipatory reference.
2. The same caution applies to EP 0679977/0679978/0679979/0681233 (foreign publications — not § 102(e) art). Cooper '946/'470 are the cleaner § 102(e) vehicles for the same disclosure.

This is the single most likely point of failure in an IPR/§ 103 challenge, and it should be handled by anchoring on Cooper plus admissions.

6. Motivation to combine, consolidated (KSR / Graham factors)

1. Same field of endeavor. All primary references are directed to protecting encrypted digital information distributed on media or over networks from unauthorized copying, while permitting authorized use. No field-crossing.
2. Same problem, same solution space. Cooper/CRYPTOLOPE and the patent attack the identical problem: how to run/consume encrypted content on a general-purpose machine without decrypting to an unprotected medium. Each reference explicitly frames the problem the patent frames.
3. The patent's own admitted motivations. The specification does the petitioner's work: it states why the TSR/helper model is inferior (public directory/file names manipulable by other programs; dependence on a third party for keys) and why memory-resident decryption is desirable. These are exactly the reasons a skilled artisan would have combined Cooper's dynamic-decryption-to-the-OS teaching with a self-contained, self-decrypting product.
4. Predictable results. Every mechanism is a documented OS primitive or a conventional data-format choice. "If a technique has been used to improve one device, and a person of ordinary skill in the art would recognize that it would improve similar devices in the same way, using the technique is obvious."
5. Design incentive / market pressure. The patent's Background documents heavy commercial pressure (DVD content withholding, CSS licensing, the market's failure to distribute content for lack of adequate protection) — classic KSR "design incentive" evidence supplying motivation.
6. No teaching away. Highlighting a weakness in the CRYPTOLOPE TSR (public directory names, third-party key control) is criticism of a specific implementation, not a teaching away from the claimed solution; if anything it directs an artisan toward the claimed self-contained, name-obscured approach.

7. Anticipated rebuttal — secondary considerations

The strongest non-obviousness arguments are likely to be:

• The "self-decrypting, self-contained product" combination was not obvious as a whole. Countered by Cooper '470's express stub-installs-encryption-and-relaunches teaching, which makes the leap small.
• Unexpected advantage: decrypted code never passes through a device driver or TSR, defeating FSD-hooking spies. This is the patent's stated advantage. Counter with (a) the debugger and anti-virus art already discussed, and (b) the fact that the NT embodiment's benefit flows predictably from known OS memory-protection semantics.
• Commercial success / licensing / litigation. The Google Patents record shows the family has litigation (E.D. Tex. case 2:08-cv-00316) and assignments to Open Security Solutions LLC, then RPX Corporation. Nexus to the claims would need a documented licensing/sales story; absent a demonstrated nexus to the specific claimed elements, this carries limited weight.
• Long-felt need. Plausible, but the need was equally framed and addressed by Cooper/CRYPTOLOPE, weakening the nexus.
• "Phantom directory" random naming. This is the most idiosyncratic limitation; if any dependent claim rises or falls on it, argue it is an optimization of a known obscurity technique in view of the patent's admitted criticism of Cryptolope's public directory names.

8. Bottom line

• The independent aspects (single distributable product = unencrypted executable logic + encrypted content, where the executable logic answers OS requests by decrypting on the fly and returning plaintext to the OS) are squarely disclosed or rendered obvious by Cooper U.S. 5,563,946 and U.S. 5,598,470, both available as § 102(e) art, especially the '470 stub that "duplicate[s] the functionality of the TSR and install[s] dynamic encryption before kicking off the application a second time."
• The strongest § 103 combination is Cooper '946 + Cooper '470 + the self-decrypting-executable teaching, the latter supplied chiefly by the patent's own Background admissions about encrypted self-decrypting viruses, with Nachenberg as corroboration only (date caveat, Section 5).
• Add the Cryptolope container art and the 40-reference licensing/royalty/distribution list for authorization, per-use, per-machine and network/DVD aspects (elements (F)).
• Add the admitted Win32 API documentation and the cited debugger art for the protected-memory and two-process aspects (element (E)).
• Cooper '470 alone is close to anticipating the FIG. 9 production-process aspect.
• The only genuinely contestable limitations are the hooked VxD + randomly named phantom directory (embodiment 1) and the random-name rendezvous generally; these are best attacked as predictable implementations responding to the patent's own admitted weaknesses in CRYPTOLOPE, rather than as § 102 art.

Confidence: High as to the Cooper-only and Cooper+admissions combinations. Medium as to anything resting on Nachenberg or the EP Cryptolope applications because of the date/§ 102(e) issues. Unverified in this session: the specific disclosures of U.S. 4,817,140, 5,412,718, 4,888,798, 5,509,074 and the remainder of the ~40-patent list — I have relied on the patent's own characterization of those, which should be independently checked before filing. I also could not confirm the literal claim language, as noted in Section 0.1.

Primary sources consulted: https://patents.google.com/patent/[US6052780](/patent/US6052780)/en ; https://patents.google.com/patent/US5563946 ; https://companyprofiles.justatic.com/patent/5598470 ; https://dlnext.acm.org/doi/epdf/10.1145/242857.242869 ; https://www.cnet.com/tech/tech-industry/hackers-cant-interlope-a-cryptolope/ ; https://www.cs.odu.edu/~mln/pubs/NASA-2001-tm211426.pdf