US 5502766

I'll search for authoritative information on this patent, including any litigation activity.

Let me search specifically for litigation involving this patent and verify claim structure.

Let me verify the full independent claim set, since the patent covers both the "data enclave" and "trusted path" inventions.

US 5,502,766 — verification summary

Sourcing note: I located and cross-checked this patent via Google Patents (patents.google.com/patent/US5502766A), FreePatentsOnline (freepatentsonline.com/5502766.html), EveryPatent, and Unified Patents' patent portal. I did not have direct API access to USPTO PatentCenter or the Federal Circuit's docket system in this session, so the litigation statement below is based on indexed public web sources, not a native docket query. Where I am uncertain I say so explicitly.

Bibliographic data

A caution on identifiers: a web search for the bare string "5502766" also returns JP 5502766 B2 (日精樹脂工業株式会社, "射出成形機の成形方法" / molding method for an injection molding machine, registered 2014‑03‑20). That is an entirely unrelated Japanese patent that merely shares the same numeric string. Per your instruction I have not merged, corrected, or conflated these two records; every statement below pertains only to US 5,502,766.

Small internal inconsistency worth flagging: Unified Patents lists the sibling US 5,276,735 with a priority date of 1992‑04‑16, whereas the patent text and Google Patents give 1992‑04‑17. Ten to one this is a database artifact, but I am not auto-correcting it.

Abstract (verbatim)

"A data communication system providing for the secure transfer and sharing of data via a local area network and/or a wide area network. The system includes a secure processing unit which communicates with a personal keying device and a crypto media controller attached to a user's Workstation. The communication between these processing elements generates a variety of data elements including keys, identifiers, and attributes. The data elements are used to identify and authenticate the user, assign user security access rights and privileges, and assign media and device attributes to a data access device according to a predefined security policy. The data elements are manipulated, combined, protected, and distributed through the network to the appropriate data access devices, which prevents the user from obtaining unauthorized data."

Plain-language overview of the independent claims

The patent describes two related inventions — the Data Enclave (cryptographically protected storage media on a LAN/WAN) and the Trusted Path (an authenticated human-to-secure-computer channel). The independent claims I was able to verify from the published claim text are three:

Claim 1 — Data enclave, apparatus/system form. A system for securing data on fixed and removable media in a network having a server and workstations. The required pieces are:

• protected storage in the server and in each workstation;
• a crypto media controller in each workstation that can read both fixed and removable media;
• a personal keying device issued to each user;
• an enclave key (a copy resident in the server and in each workstation) used to protect other keys while stored or transmitted;
• a per-user PIN;
• an access vector paired with each media key to form media-key/access-vector pairs, held in the personal keying devices and representing the conditions under which that user may access the encrypted media data;
• those pairs enciphered under a combined key that includes the user's PIN and the enclave key;
• device attributes assigned to each workstation representing its security attributes; and
• controller logic that (i) reads the media using the media key obtained from the user's personal keying device, (ii) decrypts the media key/access vector pair using the enclave key held in the controller plus the user-entered PIN, (iii) decrypts the media data with the media key, and (iv) restricts access based on the access vector and the device attributes of the workstation from which access is attempted.

In substance: keys live with the user (in a pocket-sized token), data lives on media, and authorization is decided at the last possible moment by combining the user's access vector with the machine's device attributes.

Claim 2 — Data enclave, method form. The method counterpart of claim 1, cast as steps (a) onward: providing the protected storage, the crypto media controller in each workstation, a personal keying device per user, the enclave key with copies in server and workstations, a per-user PIN, the access vector/media key pairs stored in the keying devices under a combined key including the PIN and enclave key, and the device attributes. It is essentially the same architecture expressed as a process of provisioning and organizing cryptographic material rather than as an apparatus.

Claim 3 — Data enclave, expanded attribute-based system form. A system claim that adds the fuller attribute model:

• a user UID per user, stored in the keying device encrypted with the enclave key;
• user attributes representing that user's privileges and security-relevant information;
• a media key per unit of media (stored in the keying devices);
• a media UID per unit of media, written onto the media itself, used both to look up the matching media key in the keying device and to index the media's attributes;
• media attributes representing the sensitivity/security classification of that unit of media;
• here the pairs are enciphered under a combined key including the user's UID, the user's PIN and the enclave key (note: claim 1's combined key recites only the PIN and enclave key); and
• controller access control logic restricting access based on the user's PIN, the access vector, and the workstation's device attributes.

Claim 4 (verified) depends from claim 3 and adds the key-management/initialization machinery: key management crypto logic in the controller and server, storage search logic indexing a user attribute database and a media attribute database, and security policy logic computing a new access vector from media attributes plus the requesting user's security attributes, and generating a new media key.

Uncertainty to flag: I was able to verify claims 1, 2, 3 and the dependency of claim 4, but I do not have the complete numbered claim set in front of me and therefore cannot state with confidence the total claim count or whether further independent claims exist. Based on the specification's separate discussion of the Trusted Path, it is plausible that the Trusted Path subject matter is claimed in the sibling patent US 5,499,297, "System and method for trusted path communications" (same family, listed in the search reports alongside '766), rather than in '766 itself. I would treat that as an inference, not a confirmed fact. Anyone needing the exact claim set should pull the patent from USPTO PatentCenter or the Google Patents full-text claims page.

Litigation / CAFC 2026 docket search — result

No Federal Circuit 2026 docket activity involving US 5,502,766 was found. I searched for the patent number combined with CAFC, 2026, docket, and litigation terms and returned nothing tying '766 to a 2026 appeal. Two structural reasons make that the expected outcome:

1. The patent is expired. Google Patents records the anticipated expiration as March 26, 2013, with legal status "Expired – Lifetime." An expired patent cannot support prospective injunctive relief, which sharply limits the incentive to appeal any decision concerning it.
2. The known Secure Computing litigations did not assert '766. The notable campaign involving this assignee was Finjan Software v. Secure Computing (D. Del. 2007; Fed. Cir. appeal No. 2009‑1576, Finjan, Inc. v. Secure Computing Corp., decided Nov. 4, 2010). The patents asserted there were Finjan's 6,092,194 / 6,804,780 / 7,058,822, with Secure Computing counterclaiming on its own patents. US 5,502,766 does not appear as an asserted patent in that dispute on the record I found; it shows up in PTAB/examination papers only as a cited prior-art reference (e.g., in file histories for DivX IPR2020‑00558 and in prosecution search histories), which is a very different thing from being in suit.

The one ambiguity worth naming: a FreePatentsOnline page for Prism Technologies' US 8,387,155 lists '766 in a table of prior art and also references "In the Matter of Certain Authentication Systems, Including Software and Handheld Electronic Devices" (a Section 337 ITC investigation). That listing does not establish that '766 was asserted in that investigation — it appears as a reference document. I cannot confirm or deny '766's involvement in any ITC proceeding without the ITC docket itself, and I would not rely on that snippet as evidence of litigation.

Bottom line: US 5,502,766 is a 1996 Secure Computing patent (Boebert, Markham, Olmsted) on the Data Enclave / Trusted Path architecture, now expired and held of record by McAfee LLC via the Secure Computing acquisition chain. I found no CAFC 2026 docket activity for it. The claim recitations I quoted are drawn from published claim text and are reliable; the total claim count and any claim set beyond claims 1–4 are not verified, and no assertion of this patent in identified litigation was confirmed.

I'll search litigation databases for this specific patent number.

Initial searches returned mostly unrelated hits. Let me query litigation-specific databases directly.

Let me try more targeted queries that litigation databases index.

Bottom line

I found no litigation — no district court case, ITC investigation, PTAB proceeding, or Federal Circuit appeal — in which US 5,502,766 was asserted as a patent-in-suit. Every hit my searches returned for the string "5502766" was either a coincidental numeric match to an unrelated document or a citation of '766 as prior art in someone else's file history. I state that with the confidence caveats in §5 below.

1. What I searched

I ran exact-string and combined queries designed to surface litigation aggregators rather than raw web pages, targeting: Unified Patents' litigation/PTAB case lists, RPX Insight, Docket Alarm, CourtListener/RECAP, UniCourt, PACERMonitor, Justia, and Google Patents' own litigation data. Queries included "5,502,766" paired with litigation, lawsuit, defendant, infringement complaint, asserted, district court, and with the assignee/inventor names (Secure Computing, Boebert).

Result: the search index returned no litigation record page for this patent. It did not return a Unified Patents caselist entry, an RPX Insight patent/litigation profile, or a Docket Alarm case page naming '766 as an asserted patent. I could not reach portal.unifiedpatents.com/litigation directly as a queryable API in this session, so this is an inference from the absence of indexed records, not a direct docket query (see §5).

2. Everything the searches actually returned (all false positives for this ID)

3. Where US 5,502,766 does appear in the public record

Consistently, '766 shows up only as prior art / family member, which is categorically different from being in suit:

• IPR2020‑00558, Netflix, Inc. and Hulu, LLC v. DivX, LLC — '766 appears inside the '558 petitioner's Exhibit 1002 (US 10,225,588 file history), in a USPTO examiner's EAST search-history string of cited references (... "5502766" "5509070" "5533021" ...). That is an examiner's cited-reference list, not an assertion.
• IPR2015‑00354 (US 7,774,280 file history, Exhibit 1002) — same pattern: '766 in an examiner search-history listing.
• WO 98/22862 / WO 93/21581 front-page family listing — '766 is listed as a patent-family member of the Secure Computing family alongside US 5,276,735 (the parent, per the '766 specification: "continuation of Ser. No. 07/870,556, filed Apr. 17, 1992, now U.S. Pat. No. 5,276,735") and US 5,499,297, plus EP 0737907 and AU 678937. This confirms the family structure but says nothing about litigation.

4. Consistency check against the previously generated section

This is consistent with the earlier section, which already concluded no CAFC 2026 activity existed for '766 and that Finjan Software v. Secure Computing (D. Del. 2007; Fed. Cir. No. 2009‑1576, decided Nov. 4, 2010) asserted Finjan's patents, not '766. Nothing in this round contradicts that. I still could not confirm any assertion of '766 in the ITC § 337 investigation referenced in the Prism Technologies US 8,387,155 document, and I do not treat that snippet as evidence of litigation involving '766.

One discrepancy to flag (not auto-corrected): the current task header states today is April 26, 2026, while the tool environment reports 2026‑09‑26, and the prior section framed its negative finding as a "CAFC 2026 docket" search. I am leaving the identifiers/dates as given rather than reconciling them; the substantive finding (no asserted litigation found) does not turn on which 2026 date is used.

5. Confidence and limitations — read this before relying on the negative

• Confidence that '766 was never asserted anywhere: moderate, not high. Absence of indexed records is weak evidence for a 1996 patent that expired 2013‑03‑26 ("Expired – Lifetime"). Pre‑2010 litigation data is thinly indexed in free sources.
• I did not directly query PACER, the CAFC docket, the ITC EDIS docket, or a native Lex Machina/Docket Alarm subscription database. The general web search tool returned fuzzy/semantic matches rather than the specific aggregator pages I requested, and it never surfaced a Unified Patents or RPX page for this patent number. My negative is therefore based on absence from indexed sources, not on an authoritative docket pull.
• Reason to expect a negative: the patent expired March 26, 2013 (anticipated expiration per Google Patents), which removes injunctive leverage; and the notable Secure Computing campaign in the record (Finjan, Fed. Cir. 2009‑1576) did not assert it.

To convert this from "not found" to "verified none," pull (a) portal.unifiedpatents.com/litigation/caselist filtered to this patent, (b) the RPX Insight patent page for US 5,502,766, (c) Docket Alarm / CourtListener for "5,502,766," and (d) the USPTO PatentCenter "Litigation" tab for the patent — none of which I could execute as a native query here.

Per operating rules: this is a factual search result, not legal advice, and I have not auto-corrected any identifier. US 5,502,766 (Boebert, Markham, Olmsted; Secure Computing; now of record to McAfee LLC) is the only patent addressed above; JP 5502766 B2 and every other numeric lookalike are distinct and were not merged.

Proceedings overview

Total AIA trial proceedings on file for US 5,502,766: 0 — zero active, zero claims invalidated, zero claims sustained, zero settlements, zero institution denials. The USPTO Open Data Portal returns no IPR, PGR, or CBM proceeding naming this patent as the challenged patent, and my independent web checks (run 2026-09-26) surfaced no PTAB proceeding number tied to it either. The bottom line for a defendant is that this is not a "hardened by IPR" patent and not a "claims-canceled" patent — it is an untested patent, so there is no PTAB record to lean on and no PTAB estoppel to exploit. The good news for a defendant is different in kind: the patent expired on 2013-03-26 (anticipated expiration, per Google Patents; legal status "Expired – Lifetime"), so any assertion of it must rest on pre-expiration damages rather than forward-looking relief. The defensive play here is a damages/limitations fight and a § 282 invalidity case in district court, not an IPR.

A note on why the list is empty is as important as the list itself:

• IPR was barely available during this patent's life. IPR/CBM/PGR became available on 2012-09-16. This patent expired 2013-03-26 — roughly a six-month overlap. The realistic petition window closed essentially within that period for a patent whose term was already almost fully run.
• PGR is categorically unavailable. PGR applies only to patents with an effective filing date on or after 2013-03-16. This patent's priority date is 1992-04-17 (application 08/142,904 filed 1993-10-26), so PGR never applied.
• CBM is very likely unavailable as well. CBM review required claims directed to a "covered business method" tied to a financial product or service, and expressly excluded "technological inventions." A data-security architecture of crypto media controllers, personal keying devices, and enclave keys reads as a technological invention, which would defeat CBM eligibility. (This is my analytical assessment based on the claim subject matter, not a PTAB holding — no panel ever ruled on it.)
• Low assertion pressure means low petition pressure. The prior sections found no confirmed litigation asserting '766; its appearances in PTAB papers are as a cited prior-art reference in other patents' proceedings (e.g., the file-history exhibit in IPR2015-00441 and the DivX IPR2020-00558 history noted earlier), not as a challenged patent. Well-asserted patents attract IPRs; this one, on the record I can verify, was not being asserted.

Because the structured list is empty, the per-proceeding template below has no entries to populate. I am stating that plainly rather than manufacturing proceeding numbers.

(no proceedings to enumerate)

There is no {PROCEEDING_NUMBER} to report — no petitioner, no panel, no institution decision, no FWD, no CAFC appeal on this patent. Any entry I wrote here would be fabricated, and I will not do that.

Strategic summary

Claim-level status: everything is UNTESTED. No claim of US 5,502,766 has ever been canceled, confirmed, or construed by the PTAB. The earlier verification section identified independent claims 1, 2, and 3 and dependent claim 4, but could not confirm the total claim count or whether further independents exist (supra — that uncertainty carries forward and is relevant here, because an IPR record is one of the few ways to nail down a claim set authoritatively, and we don't have one). For a defendant, that cuts both ways: there is no cancellation to point at, but there is also no PTAB construction or patentability finding that the patent owner can cite against you. You are litigating scope and validity from scratch under § 282.

Estoppel landscape: there is none, and that is a one-way ratchet in the patent owner's favor right now. § 315(e)(2) estoppel attaches only to "the petitioner in an inter partes review of a claim in a patent that results in a final written decision." With no IPR and no FWD, no one is estopped — which means no prior-art ground has been burned by anyone. Practically: every § 102/§ 103 ground remains available to you, both patents-and-printed-publications grounds and, unlike in IPR, the full statutory universe of § 112 and system/prior-use art that the PTAB cannot reach. The flip side is that you also cannot free-ride on someone else's IPR. If you want an administrative determination, you are the one who has to pay for it — and given the 2013 expiration, an IPR is of limited value except as a defensive, estoppel-generating, or leverage tool rather than a way to knock out live claims.

Pattern signals: none — this is a "cold" patent, not a campaign patent. No repeat petitioner, no serial IPRs, no patent-owner PTAB-appeal pattern (nothing to appeal), and no evidence of a defensive aggregator such as Unified Patents driving activity. Unified Patents' portal does index the patent and its sibling US 5,276,735, but indexing is not a filing. On the assignee side, the chain runs Secure Computing Corporation → Secure Computing, LLC → McAfee, Inc./McAfee LLC (Google Patents), i.e., it is a dormant portfolio asset of a large security vendor rather than an active assertion vehicle. My earlier CAFC search found no 2026 docket activity, consistent with the patent's age and expiration. The single most useful signal is the negative one: sixteen-plus years past issue with no IPR and no confirmed suit suggests this patent has not been a priority for enforcement.

Recommended next steps

Because there is no PTAB activity, the "link to the FWD and quote the disposition" path does not exist. Here is what actually applies:

1. Do not look for a PTAB silver bullet. There is no FWD to cite. If opposing counsel or a demand letter implies the patent has "survived IPR" or was "validated by the PTAB," that is unsupported — no AIA trial ever occurred. Conversely, nobody can tell you "claim 1 is dead," because it isn't; it has simply never been adjudicated.
2. Lead with the expiration date. Assertions should be measured against 2013-03-26. Confirm that date independently against the USPTO PatentCenter/ODP maintenance record and the patent's term calculations before relying on it in a filing — I am reading it off Google Patents' "anticipated expiration – 2013-03-26," not off a certified term computation.
3. If you need an administrative ruling, weigh § 315(b) carefully. If you have been served with a complaint asserting '766, the one-year IPR clock under § 315(b) is running, and the § 315(a)(1) bar applies if you first filed a DJ action. But also price in that IPR reaches only patents and printed publications under § 102/§ 103 — your best art may well be system/prior-use or § 112, which belong in district court regardless.
4. Verify the claim set before you brief anything. The full numbered claim set is not confirmed in this analysis. Pull the patent's claims from USPTO PatentCenter or the Google Patents claims view before drafting a single invalidity contention. Do not rely on the count of 4 asserted in the summary section above.
5. Monitor, don't wait. Given the empty PTAB docket, check the PTAB E2E / PTAB Decisions and the PTAB trial statistics periodically, and cross-check the CAFC docket and CourtListener for any newly filed appeal or assertion. The absence of PTAB activity is itself the substantive finding: for a 1996 patent still sitting in a large vendor's portfolio with no IPRs, the most likely near-term risk is a dormant-portfolio assertion (e.g., by a later acquirer), not a well-litigated campaign.

One flagged contradiction to carry forward: the earlier verification section reported a priority-date discrepancy between Unified Patents (1992-04-16) and the patent/Google Patents (1992-04-17). That discrepancy is immaterial to everything above — no PTAB deadline turns on it — but I am not correcting it, consistent with your instruction.

I'll search for the recorded assignment data for this patent before reconstructing the chain.

Let me dig for the specific reel/frame numbers and correspondent data.

Ownership reconstruction — US 5,502,766 ("Data enclave and trusted path system")

Sourcing note: I do not have a native API/query session against USPTO Assignment Center in this environment, so the reel/frame data below is drawn from (a) the Google Patents legal-events block carried in this patent's authoritative text, and (b) INPADOC legal-status records for sibling patents in the same Secure Computing portfolio, which share the same recording events. No reel/frame number is asserted below unless it appears in an indexed source; where a reel/frame is unknown I say so rather than guessing.

Inventors

Caveats and pattern notes:

• The patent does not record an employer for any inventor. The only determinable employer link is by assignment — the application was assigned to Secure Computing Corporation, and the three inventors are the same team that produced Secure Computing's earlier secure-architecture patents.
• Unusual-departure signal: cannot be evaluated / no evidence of one. The classic "all inventors left the assignee within 12 months of filing, precipitating a fire-sale" pattern is not observable here. To the contrary, Boebert is a repeat inventor across the assignee's earlier and later filings, and the chain shows the assignee continuing to own the patent for over a decade. I could not determine departure dates for Markham or Olmsted and will not infer them.
• Residence detail ("Minneapolis, MN") comes from a third-party inventor aggregator, not the patent face — treat as low-confidence color only.

Original assignee

• Entity named on the issued patent: Secure Computing Corporation (FreePatentsOnline). Google Patents renders the same field as "Secure Computing LLC," which is an anachronistic rendering of the later corporate name rather than the 1996 record — flagging, not auto-correcting, per prior sections. The original applicant was the Secure Computing entity of the early 1990s (Roseville/St. Paul, MN), the corporate predecessor in the chain now ending at McAfee.
• Primary line of business: network/computer security — secure operating systems and trusted network components in the 1990s, later the Sidewinder firewall family, SafeWord authentication, and SnapGear; by the mid-2000s a NASDAQ-listed enterprise security vendor (ticker SCUR).
• Did it ship a product embodying the claims? Secure Computing was unambiguously a product company, not a licensing vehicle — it sold security hardware/software to 22,000+ customers in 106 countries at the time of the McAfee deal. However, I could not confirm that a named commercial product specifically embodied the '766 Data Enclave claims; the specification itself frames the invention as an architecture built from "readily available commercial technology" rather than as a described product SKU. Treat "shipped an embodying product" as plausible but not verified.
• Current status: Acquired — not dissolved, not bankrupt. Secure Computing Corporation was acquired by McAfee, Inc.; the deal was announced September 2008 and closed on/about November 19, 2008 at $5.75/share (~$418M net, ~$462M including net cash). The brand survived as McAfee's Network Security business unit.

Assignment timeline

Five post-issuance recordings appear in the record. Execution dates are given only where the source states an effective date; otherwise the date shown is the recording date.

• 2006-09-14 (recorded; execution date not stated) — Reel/frame not retrieved

  • Conveyance: Security Agreement
  • Assignor: CipherTrust, Inc. and Secure Computing Corporation
  • Assignee: CITICORP USA, INC., as Administrative Agent
  • Correspondent: not retrieved (see §"Correspondent gap" below)
  • Context: securitization / collateral — patents pledged as collateral for a credit facility. The presence of CipherTrust (Secure Computing's newly acquired subsidiary) as co-assignor confirms this is a portfolio-wide financing lien, not an ownership transfer.

• 2008-09-12 (recorded); effective 2008-09-04 — Reel 021523 / Frame 0713

  • Conveyance: Assignment of Assignors' Interest (in substance a release of the security interest)
  • Assignor: CITICORP USA, INC.
  • Assignee: SECURE COMPUTING CORPORATION
  • Correspondent: not retrieved
  • Context: release of collateral — the security interest is discharged back to the assignee. (Reel 021523/0713 is independently confirmed for this event via INPADOC legal status on sibling Secure Computing patent US 6,357,010: "ASSIGNMENT OF ASSIGNORS INTEREST; ASSIGNOR: CITICORP USA, INC.; REEL/FRAME: 021523/0713; EFFECTIVE DATE: 20080904.")

• 2010-03-25 (recorded) — Reel/frame not retrieved

  • Conveyance: Change of Name
  • Assignor: SECURE COMPUTING CORPORATION
  • Assignee: SECURE COMPUTING, LLC
  • Correspondent: not retrieved
  • Context: change of name / internal conversion only — no change in beneficial ownership.

• 2010-05-28 (recorded) — Reel/frame not retrieved

  • Conveyance: Assignment of Assignors' Interest
  • Assignor: SECURE COMPUTING, LLC
  • Assignee: MCAFEE, INC.
  • Correspondent: not retrieved
  • Context: acquisition — recording of the Secure Computing → McAfee transfer. Flag: the recorded date (2010-05-28) lags the publicly announced close of the acquisition (~2008-11-19) by ~18 months; this is a delayed recording of a completed merger, not a second sale.

• 2022-04-11 (recorded) — Reel 059690 / Frame 0187

  • Conveyance: Corrective Assignment (confirming a Release of Patent Security Agreement); expressly corrects property numbers "previously recorded at Reel: 021523 Frame: 0713"
  • Assignor: CITICORP USA, INC.
  • Assignee: SECURE COMPUTING CORPORATION (correcting the 2008 record)
  • Correspondent: not retrieved
  • Context: correction / cleanup of the 2008 collateral release — classic housekeeping where the original release omitted property numbers and a curative filing is made years later. (Reel 059690/0187 confirmed for the same curative event on sibling US 6,357,010 via INPADOC.)

Correspondent gap (important to your brief): the correspondent of record — the attorney/agent who filed each recording, which you correctly identify as the best tell for anonymous NPE LLCs — is not exposed by any source I could reach. Google Patents' legal-events block omits it, INPADOC omits it, and the Assignment Center has no queryable API in this session. I am not going to name a firm by inference. To obtain it: pull each reel/frame above from the Assignment Center (search by patent number, then open the recording) and read the "Correspondent" field; for the un-retrieved events, query the same page and capture reel/frame + correspondent together. This is the single highest-value follow-up and I could not execute it natively.

Possible unrecorded encumbrance (flagged, not a finding): McAfee, LLC granted portfolio-wide security interests on 2017-09-29 — JPMorgan Chase at Reel 045055/Frame 0786 and Morgan Stanley Senior Funding at Reel 045056/Frame 0676 (visible on sibling McAfee patent US 7,536,456, later corrected at Reels 054206/0593, 055854/0047, 057315/0001). These are financing liens, not ownership transfers, and they post-date this patent's 2013 expiration. I did not confirm that US 5,502,766 is named in those schedules. Status: unclear.

Timeline diagram

timeline
    title Ownership of US 5502766
    1992 : Priority application filed
    1993 : Continuation application filed
    1996 : Patent issued to Secure Computing
    2006 : Patents pledged to Citicorp
         : Security agreement recorded
    2008 : Citicorp releases security interest
         : Reel 021523 Frame 0713
    2010 : Renamed Secure Computing LLC
         : Assigned to McAfee Inc
    2013 : Patent expires
    2022 : Curative release of security
         : Reel 059690 Frame 0187

NPE / troll-pattern signals

Verdict

Operating-company assertion.

Every recorded link is between operating companies or a secured lender — SECURE COMPUTING CORPORATION → SECURE COMPUTING, LLC (change of name, 2010-03-25) → MCAFEE, INC. (assignment, 2010-05-28), with the only lender entries being CITICORP's 2006-09-14 security agreement, its release at Reel 021523/0713 (effective 2008-09-04) and the curative release at Reel 059690/0187 (2022-04-11). None of the eight NPE signals is present, and the ownership chain never left the Secure Computing/McAfee corporate family, so this is not an NPE chain in any sense the record supports. Caveat I want on the record: "assertion" here describes the ownership type (the current assignee is an operating vendor), not demonstrated assertion — the patent expired 2013-03-26, no suit naming it was located, and I would not represent to anyone that McAfee has asserted it.

Verify at: USPTO Assignment Center — https://assignmentcenter.uspto.gov/ (search by patent number; mirrors at https://assignment.uspto.gov/patent/index.html) — and cross-check Google Patents legal events at https://patents.google.com/patent/[US5502766A](/patent/US5502766A)/en. The INPADOC corroboration for the two reel/frame numbers I did confirm is at https://worldwide.espacenet.com/publicationDetails/inpadoc?CC=US&NR=[6357010B1](/patent/6357010B1)&KC=B1&FT=D.

Items I deliberately did not fabricate, and you should pull natively: (a) reel/frame for the 2006-09-14 security agreement and both 2010 recordings; (b) the correspondent of record on all five recordings; (c) whether US 5,502,766 is listed in the 2017 McAfee, LLC lien schedules at Reels 045055/0786 and 045056/0676.

I'll search for the USPTO record and the specific prior-art citations listed on the face of US 5,502,766.

Let me pull the patent-citation table directly from the patent record.

The searches are returning forward citations (patents citing '766). I need the backward citations on the face of '766 itself. Let me target the patent's own "References Cited" table.

Prior-art / citation analysis — US 5,502,766

Read-this-first: a sourcing gap I will not paper over

You asked me to "look at each patent citation for 5502766" and analyze each under § 102. The operative document for that is the (56) References Cited table printed on the front page of US 5,502,766 and carried in the issued patent's official record at USPTO/Google Patents/FreePatentsOnline.

I was not able to retrieve that front-page citation table in this session. My searches returned:

• Forward citations ("Cited By" — the ~418 later patents that cite '766), and
• reference lists belonging to other patents that happen to list '766 as their own background art (e.g., the Prism Technologies US 8,387,155 and the Vainstein-family US 7,921,450 / 7,577,838 pages, and the IPR2020-00558 exhibit search history).

None of those is the "References Cited" list of '766 itself. Per your standing instruction not to fabricate identifiers or records, I am not going to reconstruct or invent a front-page citation list. Everything below is limited to citations I can actually verify from the authoritative full text you supplied plus the family record, and I flag exactly where my knowledge is registry-based rather than document-based.

1. Patent citations verified from the authoritative text

The full text you supplied expressly cites three U.S. patents, in the passage describing the implementation of the Security Server 24:

"The Security Server 24 can be implemented in the form of a secure computer for example, as disclosed in U.S. Pat. Nos. 4,621,321 to Boebert et al, entitled 'Secure Data Processing System Architecture', 4,713,753 to Boebert et al, entitled 'Secure Data Processing System Architecture with Format Control', and 4,701,840 to Boebert et al, entitled 'Secure Data Processing System Architecture'."

1.1 US 4,621,321 — Boebert et al., "Secure Data Processing System Architecture"

1.2 US 4,713,753 — Boebert et al., "Secure Data Processing System Architecture with Format Control"

1.3 US 4,701,840 — Boebert et al., "Secure Data Processing System Architecture"

1.4 Family-member references (not "prior art" in the § 102 sense)

The face of '766 also states: "This is a continuation of application Ser. No. 07/870,556, filed Apr. 17, 1992, now U.S. Pat. No. 5,276,735." Google Patents' family record for US 5,276,735 lists the sibling US 5,499,297 ("System and method for trusted path communications," Boebert) and the Australian family member AU 678937 B2.

These are same-inventive-entity family members, not third-party prior art. A parent/sibling sharing the Boebert inventive entity is not "by another" under pre-AIA § 102(a) or (e), so it cannot be used for § 102 anticipation merely by being a family member. Do not treat '735 or '297 as § 102 art against '766.

2. What the citation records do and do not tell us — a caution on the § 102 framing

Your request asks, for each reference, "which claim(s) it potentially anticipates under 35 U.S.C. § 102." Three structural points:

1. A front-page "References Cited" entry is not a § 102 finding. Patent-office citation tables are mostly § 102(a)/§ 102(b)/§ 103 background art. The examiner's printed categories (if any) and the "cited by applicant vs. cited by examiner" split are what indicate whether the office treated a reference as anticipating or merely as background. Without the actual table I cannot tell you which of these were applicant-cited vs. examiner-cited, and I will not guess.

2. Critical-date arithmetic (pre-AIA, since the '766 priority date is 1992-04-17 and the app was filed 1993-10-26). The § 102(b) one-year bar runs from the earliest U.S. filing date (1992-04-17), so a printed publication or patent published before 1991-04-17 is § 102(b) art. All three Boebert patents above (1986–1987 issuance) clear that bar comfortably — so they are available as art notwithstanding the common inventor.

3. Anticipation requires element-by-element identity. When I compare the three Boebert references to the actually-verified independent claims 1, 2 and 3 (per the FreePatentsOnline claim text recovered this session — claims 1 and 2 independent, 3 independent with claim 4 depending from 3), they do not anticipate:

   • They do not disclose a crypto media controller in each workstation that reads "the fixed media and the removable media" (claim 1(ii)/claim 2(b)/claim 3 element).
   • They do not disclose a personal keying device assigned to each user holding enciphered media key/access vector pairs, nor an enclave key with copies in server and each workstation (claim 1/2/3).
   • They do not disclose the combined key including the user's PIN and the enclave key (claim 1/2) or user UID + PIN + enclave key (claim 3) enciphering the media key/access vector pair.
   • They do not disclose device attributes compared against the access vector at the moment of access (claim 1(iv)/claim 2/claim 3).

   They are relevant only as the architectural/specification background for the "Secure Computer 24" element — i.e., § 103 material at most, and only in combination with genuinely separate cryptographic-media art.

Bottom line on § 102 for the verified citations: none of the three specifically-cited Boebert patents anticipates any of claims 1–4 on the elements I can verify. They disclose the secure-computer substrate, not the enclave/keying-token/media-encryption combination.

3. Claim set — status update from this session

This session actually confirmed (via the FreePatentsOnline full claim text) what the earlier section flagged as uncertain:

• Claim 1 — independent, data-enclave system (combined key = PIN + enclave key).
• Claim 2 — independent, data-enclave method (steps (a) onward).
• Claim 3 — independent, expanded attribute-based system (combined key = user UID + PIN + enclave key; adds user UID, user attributes, media key, media UID, media attributes, access control logic).
• Claim 4 — depends from claim 3, adds key-management crypto logic + storage search logic + security policy logic.

So there are at least four claims with three independents; the total claim count is still not verified (the recovered text did not show claims beyond 4). That earlier uncertainty is narrowed but not closed — and it matters here, because a broader independent claim I haven't seen could have a claim chart that changes the § 102 picture. Do not brief validity off a 4-claim assumption.

4. What I recommend to actually complete this task

1. Pull the (56) table directly — the authoritative front-page "References Cited" for US 5,502,766 is at:
   • Google Patents: https://patents.google.com/patent/[US5502766A](/patent/US5502766A)/en (expand "Patent Citations")
   • FreePatentsOnline: https://www.freepatentsonline.com/5502766.html
   • USPTO PatentCenter: https://patentcenter.uspto.gov (application 08/142,904) — the issued patent's PTO-892/1449 forms show examiner-cited vs. applicant-cited art.
2. When you have that table, the correct § 102 discipline is: for each reference, (i) confirm it qualifies under § 102(a)/(b)/(e) by date and inventorship, (ii) check the "by another" requirement against the Boebert/Markham/Olmsted inventive entity, then (iii) chart each verified independent claim (1, 2, 3) element-by-element. A reference that fails any single element is a § 103 reference, not an anticipation reference.
3. Reconcile the four previously flagged contradictions before relying on anything downstream:
   • the earlier priority-date discrepancy (Unified Patents 1992-04-16 vs. patent/Google Patents 1992-04-17),
   • the current-date discrepancy (this task header says 2026-04-26; the tool environment reports 2026-09-26),
   • the assignee rendering ("Secure Computing LLC" vs. "Secure Computing Corporation"),
   • and the claim-count uncertainty noted in § 3 above.
     I am not auto-correcting any of these.

5. Confidence and limitations — read before relying

• Verified from the authoritative text: the three Boebert citations (US 4,621,321; US 4,713,753; US 4,701,840) and their titles, plus the parent '735 / sibling '297 family relationship, and claims 1–4 as to independence/dependency.
• Not verified this session and therefore not asserted: the complete front-page "References Cited" list (both U.S. and foreign), the examiner-cited vs. applicant-cited split, the exact issue/filing dates of the three Boebert patents (I gave dates from database knowledge and flagged each), the total claim count, and any specific § 102(b)/§ 103 rejection the examiner actually made during prosecution.
• Per your operating rules: I have not merged, corrected, or conflated any identifier. US 5,502,766 (Boebert, Markham, Olmsted; Secure Computing; of record to McAfee LLC) is the only patent addressed here. JP 5502766 B2 (日精樹脂工業株式会社, "射出成形機の成形方法") remains a distinct, unrelated patent sharing only the numeric string, and it is not treated as a citation to or from '766.

This is a factual prior-art/citation analysis based on the record retrieved, not legal advice.

I'll start by gathering the prior-art landscape. Note up front: the material supplied in this session does not include a populated "Prior Art" section with search results — the only prior-art references actually present are those cited on the face of the patent itself (the three Boebert et al. patents). I'll verify that and search for candidate references so the § 103 analysis is grounded rather than invented.

Good — the claim set is confirmed as claims 1–4. Now let me find the actual "References Cited" on the face of '766, which is the closest thing to a prior-art section available.

Let me try to pin down the exact "References Cited" list on the face of '766 itself (not its sibling).

Framing, and one procedural flag up front

Two housekeeping points before the analysis, because they affect how much of this is grounded versus assumed:

1. There is no populated "Prior Art" search-result section in the material supplied for this session. The page text I was given contains the specification, the abstract, the classification data, and the bibliographic record — but no third-party prior-art search results. So rather than invent a reference list, I reconstructed the operative prior-art record from the two authoritative places it actually exists:

• the "References Cited" list printed on the face of US 5,502,766 itself, which I retrieved verbatim (via EveryPatent's reproduction of the front page, http://www.everypatent.com/comp/pat5502766.html), and
• the prior-art admissions in the specification, which expressly rely on the applicant's own earlier Boebert patents.

That is the correct basis for a § 103 analysis anyway, and I cite it below.

2. A claim-set correction to the earlier sections. The prior section could only verify claims 1–4 and flagged that it could not confirm the total count. I can now confirm from the full printed claim text: US 5,502,766 has at least claims 1–6. Claims 5 and 6 depend from claim 3 (they are the "key assignment to a second user" and "keying of devices" claims). This confirms — rather than contradicts — the earlier inference that the Trusted Path is claimed in the sibling US 5,499,297: every claim of '766 is a data enclave claim (claim 1 "A data enclave for…"; claim 2 "A data enclave method…"; claim 3 "A data enclave for…"; claims 4–6 "A system according to claim 3…"), and the '297 claims I retrieved are the identification/authentication, countersign, and trusted-path claims. So the "Trusted Path" half of the title is prosecuted in '297, not here.

3. One contradiction to carry forward (not auto-corrected). The earlier sections state the patent expired 2013‑03‑26 (Google Patents' "anticipated expiration"). The actual front page carries a terminal-disclaimer notice: "The portion of the term of this patent subsequent to April 17, 2012 has been disclaimed." That points to an effective expiry of April 17, 2012, roughly eleven months earlier than the Google figure. I am flagging this rather than reconciling it. It matters for any damages window.

Framework. Because the application was filed 1993‑10‑26 with a priority date of 1992‑04‑17, pre‑AIA 35 U.S.C. § 103 governs. The analysis follows Graham v. John Deere Co., 383 U.S. 1 (1966) and KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), with MPEP 2141–2144 for the articulation of reasoning. Invalidity must be proven by clear and convincing evidence. This is analyst work product, not legal advice.

1. The prior-art record actually on the face of '766

The examiner-cited U.S. references (front page, PTO‑892) are:

Foreign: EP 421409 (Apr 1991), EP 471538 (Feb 1992). Non-patent: Boebert et al., Secure Ada Target (1985) and Secure Computing: The Secure Ada Target Approach (1985‑88); Kibalo & Boebert, Using Embedded COMSEC (1986). The specification also relies on US 4,621,321 and US 4,701,840 (Boebert) as admitted prior art for the Secure Computer 24, and on US 5,272,754 in the sibling.

Note two timing cautions: 5,253,295, 5,272,754 and 5,276,735 issued after the 1992‑04‑17 critical date, so they can only be § 102(e) art (i.e., only if their applications were filed before the critical date), and to the extent they are § 102(e)/(f)/(g) art they are potentially subject to disqualification under pre‑AIA § 103(c) if commonly owned. US 4,713,753 is different — it issued 1987‑12‑15, more than a year before the critical date, so it is § 102(b) art and cannot be removed by § 103(c). That is the load-bearing reference for the Boebert-family disclosure.

2. Person having ordinary skill in the art (PHOSITA)

Circa April 1992: a computer-security engineer or systems programmer with a B.S. in CS/EE and roughly 2–4 years in secure-systems work — cryptographic key management (DES; the ANSI X9.17/ISO 8732 key-distribution model), formal access-control models (Bell–LaPadula, Biba, lattice/attribute models), TCSEC/Orange Book security kernels and the "trusted path" requirement (DoD 5200.28‑STD, 1985), and smart-card/token authentication. This PHOSITA is the reference point for "motivation" and "reasonable expectation of success."

3. Element mapping

Claim 1 / claim 2 (the two independent data-enclave claims):

Claim 3 adds: user UID stored in the token encrypted under the enclave key; user attributes; per-media media key in the token; media UID written onto the media; media attributes; access vector computed from media attributes + user attributes + access rules; wrapping under UID + PIN + enclave key; access-control logic keyed on PIN + access vector + device attributes. → Aoyama '096 (ID-indexed user attribute/level database), Preston '040 (labels carried with stored data), Boebert '753 (attribute comparison governed by rules), Ehrsam '253 (encryption of IDs under the KEK), Lang '429.

Claim 4 (media initialization and key generation) and claim 5 (re-issuing the same media key to a second user) are, element for element, the classical key-distribution-center transaction: identity validation against a user database indexed by user ID, a policy engine that computes an authorization record, generation of a data key, wrapping of that data key under a key-encrypting key derived from user credentials, archival in a key database, and delivery to the requester. → Ehrsam '253/'854, Foster '801, Aoyama '096, Preston '040, Boebert '753.

Claim 6 (the read path) is the mirror image of claim 4: unwrap user UID with the enclave key, combine UID + PIN + enclave key into the wrap key, unwrap the stored pair, route the media key to the data crypto and the access vector to the access-control logic. Same combination as claim 4.

4. The obviousness combinations, with motivation

Ground A — against claims 1 and 2

Lang '429 + Ehrsam '253/'854 + Konheim '782 (or Hällberg '872 / Saada '295) + Boebert '753 (optionally with '754).
Lang supplies per-media encryption and a key for it. Ehrsam supplies the key hierarchy that lets a media key be stored and transmitted in enciphered form under a system-level key — precisely the role '766 assigns to the enclave key. Konheim/Hällberg/Saada supply token-plus-PIN release of the key to the authorized individual. Boebert '753 supplies a secure computer that makes access decisions by comparing attributes under a rule set.

Motivation (KSR / MPEP 2143): the '766 background itself frames the problem — data on removable media is vulnerable to theft without evidence, so it must be protected on the media; but if keys live only at the media, sharing across a network is impossible, so a key hierarchy is required; and a key hierarchy requires user authentication before a key is released. These are the same field (data security), the references do not teach away, and each element performs exactly its known function in the combination. This is the "predictable results" and "known technique applied to a known device ready for improvement" rationales (MPEP 2143(A), (D), (F)).

The weakest link is the conjunctive limitation — restriction on the access vector and the workstation's device attributes. The patentee will argue the prior art decides on user entitlements or object labels, not on the cryptographic identity of the machine at the point of decryption. Counter-evidence: Boebert '753 concerns access decisions in a specific secure machine (i.e., a machine-attribute premise); Hale '652 is expressly about the remote-terminal environment; and the '766 specification itself describes the device-attribute test as policy-driven rather than as a new mechanism. This is the element most likely to be contested, and a defendant would want a terminal-location access-control reference (e.g., TCSEC trusted-facility/terminal-location practice, or a system such as Schlesinger‑type location lock-out, which is in the art) to buttress it.

Ground B — against claim 3

Aoyama '096 + Preston '040 + Boebert '753 + Lang '429 + Ehrsam '253.
Aoyama expressly discloses operator personal-identification data plus security levels that a security administrator automatically updates — user UID and user attributes. Preston '040 expressly discloses cryptographic labeling of stored data for multiple users — media attributes and multi-user key release. Boebert '753 supplies the rule-governed comparison of those attributes. The "access vector = f(media attributes, user attributes, access rules)" recitation is therefore the result of applying an attribute-comparison access-control model to the labeled-media model.

Motivation: to let a unit of media be shared, one must name the medium, describe it, name the user, describe the user, and reconcile the two at access time. Each of those five steps is a documented prior-art technique; the combination is an aggregation of known elements, not an unexpected synergy. The user UID encrypted under the enclave key is simply Ehrsam's KEK-wrapping applied to an identifier, which is the ordinary way to make a credential portable without exposing it.

Ground C — against claims 4 and 5

Ehrsam '253/'854 + Foster '801 + Aoyama '096 + Preston '040 + Boebert '753.
This is the standard KDC/X9.17 exchange dressed in the '766 vocabulary: verify the requester, look up attributes, compute the authorization, mint the data key, wrap it under a user-derived key, archive it, ship it. Claim 5 — re-wrapping the same media key for a second user with a fresh access vector — is the ordinary "key translation / re-issue to a new recipient" operation that a KDC exists to perform.

Motivation: centralized policy administration and key archival/backup. The '766 specification states outright that the Security Server "performs the key management and backup functions for the cryptography in the Enclave" — i.e., the patentee's own stated rationale for centralizing these steps is the classic administrative rationale for a KDC, which the references already implement.

Ground D — against claim 6

Same combination as Ground A plus Ehrsam's compounding of the KEK with the bearer's identifier: Lang '429 + Ehrsam '253 + Konheim '782 + Boebert '753. "Combined key = UID + PIN + enclave key" is textbook two-factor key derivation (something you have + something you know + a system secret), each contributor already in the art.

5. Where the obviousness attack is weak (the patentee's rebuttal)

I would not present this as an open-and-shut invalidity case. Four points a patentee would press:

1. The location of the authorization data. '766 stores the access vector itself in the user's token, in encrypted form, rather than in a central server, and unwraps it at the point of use. Aoyama '096 and Preston '040 are central-database / central-labeling disclosures. The patentee can argue the art lacks a suggestion to move the authorization decision into an off-line, user-borne token — which is the actual architectural claim the specification touts as an improvement over "all-or-nothing" access.
2. The placement of the crypto boundary. The claims require the crypto media controller in each workstation holding the enclave key. A patentee can argue that placing a key-encrypting key on every desktop was counterintuitive in a 1992 threat environment, so there was no motivation to do it. The rebuttal is '754 (and '321), which place a trusted cryptographic subsystem at the untrusted workstation — so the motivation does exist, but the patentee has an argument.
3. The three-phase protocol granularity of claims 4–6. The packet contents, the DB indexing choices (user UID indexes the user-attribute DB; media UID indexes the media-attribute DB; key packets retrieved by media UID), and the ordering of the initialization/assignment/keying phases are narrow. A defendant needs art that discloses re-keying the same data key to a new recipient, not merely generic KDC operation, to reach claim 5 cleanly.
4. Terminal disclaimer / double patenting. The front page's terminal disclaimer ties '766's term to the parent '735. That is a family–double-patenting fact, not an obviousness defense, but it confirms the two patents share an inventive entity and disclosure — which a patentee could use to argue the '735 disclosure is not "prior art" to '766 in the § 102(a)/(b) sense. (It is still § 102(e)/(g) art, and the disclaimer cuts against any argument that '766 added a separate invention.)

6. Secondary considerations (§ 103 objective indicia)

Arguments the patentee could marshal: long-felt need (the specification's point that removable-media theft leaves "no sign that loss has occurred"); industry adoption, evidenced by the very large citing-art record (Unified Patents lists 964 referencing documents for the sibling); evaluation by others / licensing (the assignment chain to McAfee reflects the portfolio's acquisition value). Against that: the individual mechanisms are old and commercially ubiquitous (DES, X9.17 key wrapping, smart cards), which weakens the nexus between any commercial success and the claimed combination; and my earlier searches found no confirmed assertion of '766 at all, which undercuts any inference of competitor imitation. On the record I can verify, the secondary considerations are unlikely to be decisive for this patent.

Bottom line

Grounded on the references actually printed on the face of US 5,502,766, the strongest § 103 positions are: (A) Lang '429 + Ehrsam '253/'854 + Konheim '782/Hällberg '872/Saada '295 + Boebert '753 against claims 1–2; (B) Aoyama '096 + Preston '040 + Boebert '753 + Lang '429 + Ehrsam '253 against claim 3; (C) Ehrsam '253/'854 + Foster '801 + Aoyama '096 + Preston '040 + Boebert '753 against claims 4–5; and (D) the Ground-A combination against claim 6. The motivation in every case is the same: reduce networked data protection to known primitives — encrypt the media, wrap the media key under a system KEK, release the key only to an authenticated token-plus-PIN holder, and let a rule-governed attribute comparison decide access at the point of use — which is exactly what each reference already does, in the same field, without teaching away. The genuinely contestable limitations are the conjunctive access vector + device attribute test and the off-line storage of authorization data in the user token; a well-funded invalidity contention would need additional art (terminal-location access control, and stored-authorization smart cards) to close those gaps.

Caveats: this is a prior-art/invalidity analysis, not legal advice and not a validity opinion; § 103 invalidity requires clear and convincing evidence; and the reference dates above are taken from the printed front page, which I have not verified against the certified USPTO records. Two open discrepancies are carried forward, not corrected: the 1992‑04‑16 vs 1992‑04‑17 priority-date conflict, and the 2012‑04‑17 (terminal-disclaimer notice on the face of the patent) vs 2013‑03‑26 (Google Patents' anticipated expiration) question.