US 7577839

I'll research this patent in the USPTO/Google Patents databases and check for any CAFC 2026 activity.

Let me verify the granted claims for US 7,577,839 specifically and check for any litigation/CAFC activity.

Let me verify the exact granted claims of US 7,577,839 and do a final check for CAFC/federal court activity.

US Patent 7,577,839 — Analyst Summary

Source of record: Full text fetched from https://patents.google.com/patent/US7577839/en (retrieved 2026-09-24), cross-checked against a secondary copy of the pre‑grant publication. No exact US Patent & Trademark Office "full‑text" database page was separately retrievable in this session, so the bibliographic data below is taken from the authoritative Google Patents record supplied to me.

1. Bibliographic data

Uncertainty flag: The record lists an "adjusted expiration 2024‑08‑30," which is later than the nominal 20‑year date from the 2001‑11‑16 priority (2021‑11‑16). I do not have authoritative information here explaining the offset (possible patent term adjustment and/or terminal disclaimer), so I report the date as listed rather than reconciling it.

2. Abstract (as published)

"Transferring application secrets in a trusted operating system environment involves receiving a request to transfer application data from a source computing device to a destination computing device. A check is made as to whether the application data can be transferred to the destination computing device, and if so, whether the application data can be transferred under control of the user or a third party. If these checks succeed, a check is also made as to whether the destination computing device is a trustworthy device running known trustworthy software. Input is also received from the appropriate one of the user or third party to control transferring of the application data to the destination computing device. Furthermore, application data is stored on the source computing device in a manner that facilitates determining whether the application data can be transferred, and that facilitates transferring the application data if it can be transferred."

3. Plain‑language overview of the independent claims

Important caveat on claim text: The version of the full text supplied to me did not contain the granted claims section. The claim summary below is based on the claims of US 2005/0144447 A1, which Google Patents identifies as the "other version" (pre‑grant publication) of this same application (11/068,006). Prosecution amendments between publication and grant could have changed claim wording, so treat this as likely but not confirmed for the granted claims. I was unable to retrieve the exact granted claim language within this session.

• Claim 1 (independent) — computer‑readable media programmed to back up data: The software inspects the type of an application secret that is to be backed up and branches on it:

• Non‑migrateable → the secret is not allowed to be copied to the backup medium at all.

• User‑migrateable → the secret is encrypted based at least in part on a passphrase and then allowed onto the backup medium.

• Third‑party‑migrateable → the secret is encrypted based at least in part on a third‑party key and then allowed onto the backup medium.

• Plain terms: a type‑aware "traffic‑cop" that decides how (or whether) a secret may leave the machine for backup, using different cryptographic wrapping for each class.

• Claim 7 (independent) — computer‑readable media programmed to back up data (broader sibling of claim 1): Same three‑way type test, but phrased functionally rather than cryptographically:

• Non‑migrateable → do not allow transfer to the backup medium.

• User‑migrateable → allow transfer under control of a user.

• Third‑party‑migrateable → allow transfer under control of a third party.

• Dependent claims (illustrative, from the published set): claim 2 details passphrase migration (identify the existing encryption key used for the secret, encrypt that key with the user passphrase, allow the encrypted key onto the backup medium); claim 3 does the analogous thing with the third party's public key; claims 4–5 cover the receive/restore side (obtaining a passphrase to decrypt a first group, contacting a third party to decrypt a second group); claim 6 recites that the third party may be a smartcard. Note: the published set shown to me ran at least through claim 7, so there may be additional independent claims I could not confirm.

4. Relationship to the sibling patent — avoid conflation

A different patent, US 7,577,840 B2 (same title, same 2001‑11‑16 priority, same inventors/assignee family), carries claims directed to gatekeeper storage key / hive key generation, sealing to the trusted core, and hive‑key‑based encryption of application secrets. That subject matter appears in the specification of 7,577,839 (e.g., FIGS. 9–10) but, based on the published claim set, is not the subject of 7,577,839's independent claims. I flag this because the two numbers differ by one and are easy to mix up; I have deliberately not attributed 7,577,840's claims to 7,577,839.

5. Litigation / CAFC 2026 check

I searched for 7577839 against Federal Circuit 2026 activity and Microsoft‑related dockets. I found no CAFC 2026 (or other) proceeding involving US 7,577,839.

The Microsoft‑adjacent 2026 matters my searches surfaced were all unrelated to this patent, e.g.:

• Exafer v. Microsoft — Fed. Cir. reasonable‑royalty/Enplas appeal on Azure VFP Fastpath/SmartNIC patents (network path optimization), not the '839 patent.
• Microsoft v. Sandpiper CDN (IPR2026‑00095, patent 8,478,903) and Microsoft v. ToutVirtual (IPR2026‑00295, patent 11,656,915) — unrelated.
• Qomplx v. Microsoft (W.D. Tex., patents 11,539,663 / 12,143,424 / etc.) and Semantic Copilot suit (patent 8,239,358) — unrelated.

Confidence note: absence of a hit is not proof of absence of litigation; a docket search limited to general web sources could miss a lower‑visibility case. But nothing I found links patent 7,577,839 to any 2026 Federal Circuit docket.

6. Bottom line

US 7,577,839 is a Microsoft continuation patent (priority 2001‑11‑16; filed 2005‑02‑28; issued 2009‑08‑18) covering type‑classified transfer/backup of application secrets in a trusted computing environment — non‑migrateable secrets cannot leave, user‑migrateable secrets are wrapped with a user passphrase, and third‑party‑migrateable secrets are wrapped with a third party's key, with the destination device authenticated before transfer. It is now marked expired. The only material uncertainty in this summary is the exact granted claim text, since I could not pull the issued claims directly and instead relied on the corresponding pre‑grant publication.

I'll search for litigation involving US patent 7577839.

Let me search more targeted litigation sources.

Let me try more specific searches, including the Unified Patents portal and CourtListener.

Litigation Search Results for US Patent 7,577,839

Bottom line

Based on the searches I was able to run, I found no record of any litigation involving US Patent No. 7,577,839. I could not identify any case—district court, Federal Circuit, ITC, or PTAB—in which this specific patent number appears as an asserted patent.

I want to be explicit about the confidence level here: I did not find affirmative evidence of litigation, but I also cannot rule out litigation that my searches simply failed to surface. The search results returned were largely noise (unrelated patents, a pharmaceutical Hatch-Waxman case, a chemistry paper, and coincidental numeric matches such as a Lithuanian registry filing number "7577839"), none of which concerned this patent.

Caveats on methodology (important for a legal question)

• My searches hit general web indexes and did not reliably return structured litigation records from Unified Patents' litigation portal (portal.unifiedpatents.com/litigation/caselist), PACER, CourtListener/RECAP, or Docket Alarm for this number.
• Several higher-quality sources (Unified Patents Portal, Docket Alarm, CourtListener) are effectively behind search/database interfaces that my web-search tool could not query directly, and my final attempt to hit docketalarm.com returned a "maximum number of steps" error before completion.
• The Google Patents page for US7577839 that I reviewed lists an assignment history (Microsoft Corp → Microsoft Technology Licensing LLC, 2014) and a legal status of "Expired – Fee Related" with an adjusted expiration of 2024‑08‑30, but it does not display an associated litigation/PTAB case list.

Because the strict rule is to interpret identifiers literally and not to substitute similar numbers, I want to flag that a number of near-miss results appeared — e.g., US 7,577,874, US 7,577,339-family references, and various patents ending in "783" — and none of these are US 7,577,839. I am not attributing any of them to this patent.

Patent identification (to confirm we are aligned on the right asset)

• Patent: US 7,577,839 B2
• Title: "Transferring application secrets in a trusted operating system environment"
• Application: US 11/068,006 (filed 2005‑02‑28); continuation of Ser. No. 09/993,340 (filed 2001‑11‑16)
• Priority date: 2001‑11‑16
• Inventors: Paul England; Marcus Peinado; Daniel R. Simon; Josh D. Benaloh
• Original assignee: Microsoft Corp.; current assignee Microsoft Technology Licensing LLC
• Publication: US 2005/0144447 A1; granted 2009‑08‑18
• Legal status (per Google Patents): Expired – Fee Related

Requested case table

Recommended next steps to confirm definitively

Since a negative search result from general web search is not conclusive for litigation clearance, I would verify directly against primary/structured sources before relying on this:

1. USPTO Patent Center / Patent Assignment & "External Links" for US 7,577,839 — confirm no litigation certificate (35 U.S.C. § 290 filings) is on record.
2. Unified Patents Portal litigation case list, filtered by patent number 7577839.
3. CourtListener / RECAP docket search and PACER (national case query) for "7,577,839."
4. PTAB (PTAB E2E / PTAB API) for any IPR, PGR, CBM, or derivation involving this patent.
5. Lex Machina, Docket Navigator, or Lexis/Westlaw litigation databases if you have licensed access — these are the most reliable for a clean negative.

If you can provide access to or export from any of the above (or paste the relevant docket lists), I can compile and cite the specific cases, case numbers, filing dates, and outcomes directly. I will not populate the table with anything I cannot ground in a source.

I'll verify the structured-list default ("no PTAB activity on file") against live sources before writing anything down.

No PTAB hits so far. Let me probe a few more angles — litigation history, patent-family IPRs, and the PTAB API/decision portals directly.

Let me run a final check on the family and on patent-owner-side appeal activity before concluding.

Proceedings overview

Total AIA trial proceedings on file for US 7,577,839: 0. Zero IPRs, zero PGRs, zero CBMs, zero derivations. No active proceedings, no claims invalidated by the PTAB, no claims sustained by the PTAB, no settlements, no FWDs, and therefore no PTAB appeals to the Federal Circuit. The structured "PTAB proceedings on file" block (USPTO ODP) is canonical and returned none, and my independent web checks for petitioner-side filings, family-level IPRs, and CAFC activity surfaced nothing probative for this patent number — only false-positive hits on unrelated patents, patent family annexes, and a Lithuanian registry notice that happens to contain the digit string "7577839."

The bottom-line defensive posture is therefore unusual and worth stating precisely: this is not a "hardened by surviving IPRs" patent, and it is not a "claims already canceled" patent. It is an untested patent in the AIA-trial sense — and, more importantly for a defendant, the structured data shows it is expired. Google Patents' legal-status block lists "Expired - Fee Related," with an adjusted expiration of 2024-08-30. If your demand letter is asserting this patent against current conduct, the expiration date is a more powerful first-line defense than any IPR outcome would have been.

Proceedings

No entry-by-entry section follows, because there are no proceedings to enumerate, and I will not invent proceeding numbers to populate the template. Specifically, the following cannot be reported and are not reported: no petition filing dates, no institution or denial decisions, no judge panels, no asserted grounds, no Final Written Decisions, no claim-level cancellations or confirmations, no settlement/termination dates, and no Federal Circuit docket numbers or dispositions.

To be explicit about the evidentiary posture rather than implying absence of research:

• Petitioner-side IPR/PGR activity: none found in the ODP block or in web searches. Probes for "7577839" IPR, US 7577839 PTAB inter partes review, "Transferring application secrets..." IPR PTAB petition, and Microsoft/Unified Patents combinations returned no filings naming this patent.
• Patent-owner-side appeal activity: none found. A CAFC appeal is only possible from an adverse PTAB or district-court judgment; with no PTAB trial and no litigation judgment surfaced, there is nothing to appeal.
• Caveat, stated honestly: my web checks were bounded (I hit a tool-call limit before completing every query), and PTAB activity is not the only post-grant exposure. I did not verify ex parte reexamination, reissue, or district-court invalidity holdings for this patent. Those live in different dockets and should be confirmed before you finalize a defensive opinion. Canonical sources to check directly: PTAB E2E and USPTO Patent Center for the full file history, and CourtListener / PACER for litigation.

Strategic summary

Claim status — every claim is UNTESTED at the PTAB. Because no AIA trial was ever instituted, there is no IPR-narrowed claim set to rely on. Claims 1 through whatever the last claim is (claims were not in the text provided to me, so I will not state a number) all remain exactly as granted, subject only to whatever the original prosecution produced. There are no canceled claims to point at in a Rule 12 motion, and no PTAB estoppel record to mine. Anyone who tells you "the IPR killed the key claims" is wrong about this patent.

Estoppel landscape — there is none, and that cuts both ways. With no IPR/PGR, § 315(e)(1) and § 315(e)(2) estoppel never attached to anyone. That means a defendant is not blocked from raising any prior-art ground, including § 102/§ 103 art that would have been the natural subject of an IPR. It also means the patent owner has no adverse PTAB record to distinguish, and you get no free FTC-style credibility findings from a PTAB panel. Practically, the full universe of printed publications, patents, and system art predating the 2001-11-16 priority date is on the table for a district-court § 282 challenge, subject to the ordinary IPR-minded judge's willingness to let you try validity.

Pattern signals — none, and the reason matters. No repeat petitioner, no Unified Patents or other defensive aggregator in the chain, no serial IPR campaign. The absence is itself the signal here, and it points at the patent's age rather than its strength: the application was filed as a continuation of Ser. No. 09/993,340 (priority 2001-11-16), it issued 2009-08-18, it is now listed as expired (adjusted expiration 2024-08-30), and the pre-grant publication was US 2005/0144447 A1. Patents of this vintage that get asserted aggressively attract IPRs; ones that sit in a large corporate portfolio (current assignee Microsoft Technology Licensing LLC, per the reassignment recorded 2014-12-09) frequently never do. Do not read "no IPR" as "strong" — read it as "never worth anyone's filing fee to attack, and possibly never asserted."

Recommended next steps

1. Lead with expiration, not validity. Confirm the term on USPTO Patent Center for US 7,577,839 (application 11/068,006). The structured data shows "Expired - Fee Related" with an adjusted expiration of 2024-08-30. If that holds, there is no prospective relief for post-expiration conduct, and your damages exposure collapses to the § 286 six-year lookback window for past infringement — a math problem, not a war. Verify whether the expiration reflects a maintenance-fee lapse, and whether any related continuation in the same family (there is at least one: the parent of this continuation is Ser. No. 09/993,340) is still in force and separately assertable.
2. Confirm the negative directly, then memorialize it. Pull the Application Data tab in PTAB E2E for US 7,577,839 and save the "no proceedings" screen. Also check for ex parte reexamination and reissue in Patent Center, which I could not verify. A contemporaneous record that no AIA trial exists is useful when opposing counsel implies otherwise.
3. Do not spend IPR money yet. There is nothing at the PTAB to respond to, and — critically — with the patent expired, an IPR would be a poor use of funds. If the patent owner asserts it anyway, the cheaper path is a § 282 invalidity and damages-window defense in the coercing forum, or a motion targeting the demand letter itself if it asserts expired claims.
4. If you are on the patent-owner side, the honest read is that this patent is a candidate for a family-wide enforcement review rather than a standalone assertion: the AIA-trial vacuum means the claims carry no PTAB scars, but the expiration means any value lies in past, not future, conduct.
5. What I could not do, restated. I did not locate and cannot cite any Final Written Decision, institution decision, or Federal Circuit opinion for this patent, because none appears to exist. I have deliberately cited no PTAB or CAFC document URLs for that reason — linking to a document that doesn't exist would be worse than linking to nothing.

I'll research the assignment record for US 7,577,839 using the USPTO Assignment Center and cross-referenced sources.

Assignment & Ownership Reconstruction — US 7,577,839

Analyst note on sourcing. I could not query the USPTO Assignment Center API directly from my tools; my findings rest on (a) the authoritative Google Patents legal-events record reproduced in the full patent text provided to me, and (b) an Espacenet INPADOC legal-status record that documents the standard Microsoft→Microsoft Technology Licensing, LLC conveyance for a different Microsoft patent (US 2007/0182999 A1). Where I am extrapolating the reel/frame from the analogous Microsoft transaction rather than reading it off this patent's own record, I say so explicitly. I did not fabricate any reel/frame.

---

Inventors

All four named inventors were Microsoft personnel at the 2001-11-16 priority date; the work is consistent with Microsoft's trusted-computing / NGSCB ("Palladium") research program of that era. No unusual departure pattern observed: I found no evidence of any inventor leaving the original assignee within 12 months of filing, and the patent remained under Microsoft ownership continuously until the 2014 intra-corporate transfer (see below). Caveat: I could not independently verify each inventor's full tenure record, so "no departure pattern" is a negative finding from available sources, not a positive certification.

---

Original assignee

Microsoft Corporation (Redmond, WA) — named on the issued patent (granted 2009-08-18).

• Primary line of business: operating-company software publisher (Windows, Office, server/cloud platforms).
• Product embodying the claims: The specification describes a trusted OS environment with sealed gatekeeper storage keys, hive keys, secret-type classification (non-migrateable / user-migrateable / third-party-migrateable), and migration of application secrets. Microsoft shipped related trusted-computing technology (e.g., TPM-based measured boot and BitLocker in Windows Vista and later), and the security model described here maps closely to Microsoft's NGSCB architecture. I cannot confirm that any specific Microsoft product practices the issued claims — that is a claim-charting question, not an assignment question.
• Current status: Operating. The patent is now held by Microsoft Technology Licensing, LLC, Microsoft's wholly-owned patent-holding subsidiary (formed 2014). Legal status per Google Patents: Expired – Fee Related, adjusted expiration 2024-08-30.

---

Assignment timeline

The only post-issuance assignment of record shown in this patent's legal-events history is the 2014 Microsoft-internal reorganization. Standard pre-issue inventor→Microsoft assignments are routine for Microsoft filings but were not independently verifiable in the sources available to me, so I do not state a reel/frame for them.

• Effective 2014-10-14 / recorded 2014-12-09 — Reel 034543/0001 (reel/frame per the analogous, Espacenet-documented Microsoft→MTL conveyance; not read off this patent's own record)
  • Conveyance: Assignment of Assignor's Interest (recorded as a "reassignment" in Google Patents legal events)
  • Assignor: Microsoft Corporation
  • Assignee: Microsoft Technology Licensing, LLC
  • Correspondent: Not retrievable with the tools available — I could not pull the correspondent of record for this entry, so I will not guess. (For context only, Microsoft's recording correspondence in this period ran through its own Law & Corporate Affairs department and outside firms such as Wolfe-SBMC, Spokane WA; I am not attributing those to this reel/frame.)
  • Context: Internal corporate reorganization — Microsoft moved large tranches of its patent portfolio into its wholly-owned licensing subsidiary; this is a change of owner within the same corporate family, not a sale to a third party.

No other recorded assignments (no security agreements, no third-party sales, no cascading LLC transfers) appear in this patent's legal-events history. That absence is itself the key finding: the asset never left the Microsoft corporate family.

Verify directly: USPTO Assignment Center — search patent number 7577839.

---

Timeline diagram

timeline
    title Ownership of US 7577839
    2001 : Priority application filed by Microsoft
    2005 : Continuation filed as US 11 068 006
    2009 : Patent granted to Microsoft Corporation
    2014 : Assigned to Microsoft Technology Licensing LLC
         : Intra corporate reorganization
    2024 : Patent expired fee related

---

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The sole post-issuance transfer (effective 2014-10-14 / recorded 2014-12-09) moves the patent from Microsoft Corporation to Microsoft Technology Licensing, LLC, its wholly-owned operating-company subsidiary, not to an unrelated single-purpose LLC. The "Licensing" name suffix is present, but per the rules a naming tell is only a finding when paired with no-products / registered-agent-address / single-purpose evidence — none of which is present here. This is a standard corporate IP-holding structure.

2. Known asserter in the chain — not present. Neither assignee (Microsoft Corporation, Microsoft Technology Licensing, LLC) appears on the RPX / Unified Patents high-frequency-plaintiff directories. MTL is a practicing-entity's subsidiary, not an acquirer-assertion vehicle of the Acacia / Marathon / IV / Wi-LAN type.

3. Repeat correspondent across the chain — unclear. There is only one post-issuance link, so the "recurrence" test cannot be run; and I could not retrieve the correspondent of record for this reel/frame. No finding either way.

4. Cascading transfers — not present. A single post-issuance event, not a chain of consecutive LLC-to-LLC assignments within 24 months.

5. Pre-litigation transfer — not present. No infringement suit naming this patent was located (consistent with the prior litigation section), so there is no litigation to date the transfer against.

6. Bankruptcy fire-sale — not present. No Chapter 7/11 proceeding involving Microsoft Corporation as assignor; no court-supervised patent sale.

7. Privateering — not present. No evidence that Microsoft transferred the patent to an NPE to assert on its behalf; the transferee is Microsoft's own subsidiary and Microsoft remains the ultimate parent.

8. Defensive aggregator (anti-NPE) — not present. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN; it terminates at Microsoft Technology Licensing, LLC.

---

Verdict

Insufficient data (with an affirmative finding of no NPE pattern).

Justification: The record shows a single post-issuance event — Microsoft Corporation → Microsoft Technology Licensing, LLC, effective 2014-10-14 and recorded 2014-12-09 (~Reel 034543/0001) — which is an intra-corporate reorganization of a wholly-owned operating-company subsidiary, not a transfer to an unrelated asserter. All eight NPE signals test negative; the only near-signal is the "Licensing" name suffix, which is expressly not a finding on its own. Because no third-party assignment and no litigation exist, the chain is best described as an operating-company-held asset with no NPE characteristics, and the constrained option "Insufficient data" is the closest fit — the honest bottom line is not an NPE asset, and not an assertion vehicle.

I'll research US Patent 7,577,839's cited prior art references, grounding each in retrievable sources.

Let me pull the specific citation lists from the patent's front page and databases.

Scope note and a necessary caveat up front

I attempted to retrieve the authoritative front-page "References Cited" (56) list for US 7,577,839 directly. My tooling is web search only — it cannot execute a structured query against USPTO Patent Public Search (PatFT/Patent Center), the USPTO Open Data API, or Google Patents' "Patent Citations" table. Despite multiple targeted queries, the citation table for 7,577,839 did not come back (the Google Patents page returned only the specification text; Justia returned the companion record).

So I have to be explicit about what is grounded and what is inferred:

• Grounded: the patent's identity, its claims (recovered in full), its self-disclosed related applications, and the reference list of its companion record US 7,577,840 (same inventors, same assignee, same 2005‑02‑28 filing date, same continuation parent 09/993,340 → common specification).
• Inferred (flagged): that the face-of-'839 citation list is substantially identical to the companion's, because both are continuations of the same parent application and share the same disclosure. I cannot yet prove identity of the two lists.
• Not done: I did not read the full text of each reference, so the § 102 mapping below is a claimed-element-level hypothesis, clearly hedged, not a formal anticipation chart.

Conflict flag (as requested): the previously generated litigation section states the patent is "Expired – Fee Related, adjusted expiration 2024‑08‑30," which matches the Google Patents record I retrieved — no contradiction. One small discrepancy surfaced elsewhere: the Unified Patents portal page for parent publication US 2003/0097558 A1 lists a priority date of 2001‑11‑15, while Google Patents lists 2001‑11‑16 for '839. That is a one-day discrepancy between databases on the parent record and has no bearing on the reference list, but I am noting it per the "do not auto-correct, flag contradictions" rule.

---

1. Patent confirmation (USPTO-consistent)

The three grants are the same invention described three ways — '839 is directed to the method/CRM for storing and migrating secrets by type, while '840 claims the backup variant and '230 the transfer variant. This matters for prior art: any reference cited on one is presumptively relevant to the other two.

---

2. Claims that the prior art must be measured against

Independent claim 1 (method):

1. generating a gatekeeper storage key (GSK);
2. sealing the GSK to a trusted core executing on the computing device;
3. receiving a request to store an application secret;
4. receiving a type of the application secret;
5. selecting an appropriate hive key based at least in part on the type;
6. encrypting the application secret using the hive key; and
7. encrypting the hive key using the GSK.

Dependent/subsequent:

• 2–4: create-or-reuse logic for hive keys; per-application and per-secret hive keys.
• 5: the tri-partite taxonomy — non-migrateable / user-migrateable / third-party-migrateable.
• 6–7: on a transfer request, decide whether to migrate based on type (non→never; user→under user control; third-party→under third-party control).
• 9–14 (CRM claims): select one of several encryption keys based on how the data is permitted to be transferred; plus the backup variant (passphrase for user-migrateable; third-party public key for third-party-migrateable).

---

3. Prior-art references

3a. US patent documents cited (grounded via the companion record US 7,577,840)

I want to be candid: Griswold '504 was the only US patent reference I could concretely pull from the companion record's snippet. The full US-patent reference table was truncated in my retrievals. I will not invent numbers, dates, or inventors to fill the table — doing so would violate the "interpret literally / do not fabricate" rule. The US-document list therefore needs to be pulled directly from the '839 front page (see § 6).

3b. Foreign patent documents cited (grounded via companion record)

(These three appear on the companion record's foreign-documents list. Because the two continuations share a specification and were examined on the same day, they are very likely on '839 as well — but I flag this as unverified.)

3c. Non-patent literature cited (grounded via companion record)

3d. References named inside the '839 disclosure itself (highest-value § 102(e) candidates)

The specification expressly cross-references two Microsoft applications, which are therefore the most probative § 102(e)-style art because they are earlier-filed, commonly-owned, and directed to the same trusted-OS architecture:

• Ser. No. 09/227,611 — "Loading and Identifying a Digital Rights Management Operating System." (Microsoft; filed Jan. 1999.) Related to the granted US 6,327,652 B1.
• Ser. No. 09/227,561 — "Digital Rights Management Operating System." (Microsoft; filed Jan. 1999.) Related to the granted US 6,330,670 B1.

These predate the 2001‑11‑16 priority by ~34 months and describe a trusted core that (i) is identified by a cryptographic measure and (ii) holds secrets sealed to that identity — i.e., the "sealing the GSK to a trusted core" and "trusted core" limitations of claim 1. Confidence flag: I am confident the two serial numbers are correct (they are quoted verbatim in the '839 text I retrieved). I am less certain which serial maps to which granted patent number; that mapping should be confirmed before being used in a chart.

---

4. Bottom-line § 102 assessment

1. Claim 1's wrapping structure is weak against the cited art, but its "type-based hive-key selection" is not clearly anticipated. The two-level wrap (secret→hive key→GSK) is standard key-hierarchy practice documented in Applied Cryptography pp. 574–577, and seal-to-trusted-identity storage is squarely in Yee (1994), Clark (1994), and Arbaugh/AEGIS (1997). However, no single cited reference appears to teach selecting the wrapping key based on a migration-permission type of the secret — that is the likely novelty hook, so § 102 risk on claim 1 is low and this art is realistically § 103 material.

2. Claims 5–7 (non-/user-/third-party-migrateable taxonomy) are the most robust claims. None of the retrieved references discloses a three-way migration taxonomy with distinct control authorities (user passphrase vs. third-party key). Closest are the DRM/escrow-flavored items (Murphy, SanDisk/Microsoft press) and the named Microsoft DRM-OS applications — none of which on their face disclose the specific tri-partite type scheme.

3. Claims 9–14 (CRM/backup) inherit claim 1's weakness; the passphrase-wrap and third-party-public-key-wrap techniques are individually well-known (Schneier; Abadi; Lin), so these claims are exposed to § 103 combinations even if not to clean § 102 anticipation.

4. Important procedural point: everything in § 3a–3c is a reference the examiner already considered and allowed over. Cited-and-overcome art is not, by itself, anticipating art. Any serious § 102/§ 103 challenge should look outside this list at the broader 1994–2001 trusted-computing literature (e.g., the TCPA/TCG precursors, Terra/VM-monitor work, InterTrust/ContentGuard escrow art) and at the DRM-OS family above.

---

5. What I could not verify (and why it matters)

• The complete US-patent reference table for '839 — truncated/unavailable through web search. My table shows only Griswold '504 as a grounded US reference.
• Whether '839's face-of-patent list is identical to '840's — plausible (common spec) but unproven.
• The full text of each reference — so the "claims implicated" column is a reasoned hypothesis, not an element-by-element chart.
• The serial-to-patent mapping for 09/227,611 and 09/227,561 — the serials are verbatim from the patent; the grant numbers are my recollection and are flagged.

I did not substitute any similar-but-different number (e.g., 7,577,840, 7,577,874, 7,577,339) for 7,577,839; where a companion record was used, it is labeled as such.

---

6. Recommended verification to close the gaps

1. USPTO Patent Center / PatFT for 7,577,839 → "References Cited" and "Referenced By" tables (authoritative, will confirm or correct § 3a/3b).
2. Patentimages PDF for US 7,577,839 (the front page (56) block) — this prints the exact US/foreign/NPL lists.
3. USPTO Open Data / PatentsView API (/patents/{patent_number}/...) to programmatically pull cited and citing patents.
4. Confirm the 09/227,611 → grant and 09/227,561 → grant mappings.
5. If a formal invalidity chart is the goal, pull the Google Patents "Cited By" list too — citing art often reveals the examiner's real basis of allowance and the strongest § 103 combinations.

If you can paste the (56) block from the '839 front page (or grant a source I can read), I will convert § 3 into a complete, element-by-element § 102/§ 103 table with no inferred rows remaining.

I'll ground the key references and try to resolve the claim-set discrepancy flagged between the earlier sections before building the § 103 analysis.

The search just confirmed a key contradiction to resolve: the RPX record shows that the GSK/hive-key method claim is claim 1 of US 7,577,840 B2, not '839. Let me pull the actual '839 claim set.

Obviousness Analysis under 35 U.S.C. § 103 — US 7,577,839 B2

Analyst date: April 26, 2026 · Reference set: drawn from the Prior Art section of this page (no new art introduced) · Cross-referenced to: the Patent summary, Litigation, PTAB, Assignment, and Prior Art sections already generated.

---

0. Threshold correction — a contradiction in the previously generated sections must be flagged and resolved

The task rules require me to flag contradictions, and there is a real one between two earlier sections:

• The Patent summary section states that '839's independent claims are directed to type-classified backup/transfer of application secrets (claim 1 = CRM to back up data; claim 7 = broader functional sibling), and that the gatekeeper-storage-key/hive-key subject matter belongs to the companion patent US 7,577,840 B2.
• The Prior Art section reconstructed '839 claim 1 as the GSK method ("generating a gatekeeper storage key … sealing … receiving a type … selecting an appropriate hive key … encrypting the application secret using the hive key … encrypting the hive key using the GSK").

I checked this against live sources, and the search results confirm the Patent summary, not the Prior Art section:

• The RPX/Insight record for US 7,577,840 B2 reproduces its first claim verbatim as the GSK method claim ("generating a gatekeeper storage key by a trusted core … sealing … selecting an appropriate hive key based at least in part on the type … encrypting the application secret using the hive key; and encrypting the hive key using the gatekeeper storage key"). That is '840's claim 1, not '839's. (https://insight.rpxcorp.com/patent/[US7577840B2](/patent/US7577840B2))
• The Google Patents record for the parent's pre-grant publication US 2003/0097558 A1 shows the backup-side claim language, e.g. claim 43, "One or more computer readable media having stored thereon a plurality of instructions for backing up data on a computing device … check, for an application secret to be backed up, a type of the application secret; if the application secret type is non-migrateable, then not allow the application secret to be transferred to a backup medium," and a parallel "third party-migrateable" branch. (https://patents.google.com/patent/US20030097558A1)

Resolution (ground truth for the rest of this analysis): '839's claims are the secret-type-classified transfer/backup claims; the GSK/hive-key hierarchy is claimed in the companion US 7,577,840 B2. Per the strict rule, I prefer the search results over the earlier reconstruction. I flag that the Prior Art section's element-by-element chart for '839 was, in substance, charting '840's claim 1 — which means its "claim 1's wrapping structure is weak … but its 'type-based hive-key selection' is not clearly anticipated" conclusion was applied to the wrong patent number. The correct obviousness analysis for '839 is below, and I add a labeled fallback section (§8) covering the GSK/hive-key subject matter in case the granted '839 set differs (the full text supplied to me omitted the claims section).

I also note, as the Prior Art section did, that I could not retrieve the front-page (56) citation table directly; the reference set is the one the earlier section grounded from the common-specification companion and the disclosure itself. Everything below is built only on that set.

---

1. Governing framework and the person of ordinary skill

Statute and case law. 35 U.S.C. § 103; Graham v. John Deere Co., 383 U.S. 1 (1966) (scope/content of prior art; differences; PHOSITA level; objective indicia); KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007) (a combination need not be taught explicitly; predictable variation and "finite number of identified, predictable solutions" support obviousness); In re Keller, 642 F.2d 413 (CCPA 1981) (test is what the combined teachings suggest, not bodily incorporation); In re Mouttet, 686 F.3d 1322 (Fed. Cir. 2012) (no "actual physical substitution" required). MPEP § 2143 supplies the enumerated rationales, which I apply expressly in §6.

PHOSITA (as of the 2001-11-16 priority date that '839 shares with its parent 09/993,340 — see Patent summary §1 for the term/expiration caveat). A person with a bachelor's degree in computer science or electrical engineering and 2–4 years of experience (or a master's degree and 1–2 years) in secure operating systems and applied cryptography, familiar with: secure coprocessors and tamper-resistant hardware; public-key and symmetric key management and key wrapping; boot-time integrity measurement/attestation; and the then-emerging digital-rights-management ("DRM") debate over content/key mobility. This is the level used throughout the Prior Art section and is not in dispute.

---

2. The claims to be tested (element decomposition)

Because the granted claims were not in the supplied full text, I test the claim concepts the Patent summary section recovered from the corresponding pre-grant publication, now corroborated by the US20030097558A1 text above. Where I rely on that corroboration I say so; the element labels below are mine.

Independent claim 1 — computer-readable media programmed to back up data:

Independent claim 7 — functional sibling: same three-way type test phrased as control rather than cryptography — non-migrateable → no transfer (7.2); user-migrateable → transfer under user control (7.3); third-party-migrateable → transfer under third-party control (7.4).

Dependents (per Patent summary §3): claim 2 — identify the key already used to encrypt the secret and encrypt that key with the user passphrase; claim 3 — the analogous step with the third party's public key; claims 4–5 — the restore side (obtain passphrase to decrypt the first group; contact the third party to decrypt the second group); claim 6 — the third party may be a smartcard. The abstract additionally recites authenticating that the destination is "a trustworthy device running known trustworthy software," which I map as element 1.5 in case it appears in an independent claim.

Scope note: The specification's migration and backup flows (FIGS. 9–11) tie the encryption key to a hive key that is itself wrapped by a gatekeeper storage key. But the '839 claim concepts above recite only the type-based branching and the passphrase / third-party-key wrapping; they do not require the GSK hierarchy. That distinction is important — it makes '839 broader and therefore easier to invalidate than '840, not harder.

---

3. The reference set, grouped by what it contributes

---

4. Element-by-element § 103 mapping

Combination A — the core case (Yee + Schneier + Abadi + Clark/BITS)

Combination B — destination authentication (Arbaugh/AEGIS + Lampson + MS DRM-OS applications)

For element 1.5, the combination of an attestation root (Arbaugh/AEGIS) with authentication/delegation theory (Lampson) and Microsoft's own earlier DRM-OS applications (09/227,611; 09/227,561 — a trusted core identified by a cryptographic measure) supplies: (a) a trusted core, (b) a way to prove its identity to a remote party, and (c) the practice of conditioning release of a secret on that identity. A POSITA implementing a secret-migration feature would naturally require the destination to prove it runs trusted code before handing it a migration key.

Combination C — the full claim set = A + B.

Combination D — the GSK/hive-key subject matter (labeled fallback; see §8)

Yee + Arbaugh/AEGIS + Schneier + MS DRM-OS apps: seal a root key to the trusted core (Yee/AEGIS/MS apps) and wrap per-secret keys under that root (Schneier key hierarchy).

---

5. Why the differences from the art are, on balance, obvious

Taking the Graham differences one at a time:

1. The two-level wrap (secret → hive key → GSK) as such is not even claimed in '839, and to the extent it is, it is textbook key hierarchy (Schneier). The Prior Art section reached the same conclusion ("standard key-hierarchy practice documented in Applied Cryptography pp. 574–577").
2. Sealing / non-exportable custody is squarely in Yee (1994), Clark/BITS (1994), and Arbaugh/AEGIS (1997).
3. The "inventive" kernel is the tripartite classification and the branching it drives. That is a policy choice layered on known cryptography. The set of possible controllers of a migration decision is closed and small — (i) nobody, (ii) the user, (iii) a third party — and KSR holds that where a finite number of predictable solutions exists, a skilled artisan's arrival at one of them is not inventive. 550 U.S. at 421.
4. The motivating fact pattern was public and pressing. By 1999–2000 the trade press (Murphy; SanDisk/Microsoft) was reporting precisely the policy at issue — content-owner keys "licensed to several of a user's devices, and yet not freely movable to any other device." The '839 specification uses that verbatim as its example. When the market frames the problem in these exact terms, the gap to the claimed solution is a design choice, not an invention (MPEP 2143 rationales (e), (f)).

---

6. Express KSR / MPEP § 2143 rationales (motivation to combine)

Common sense / same field. All references address the same problem — protecting secrets in an untrusted-host environment while still permitting legitimate movement — and would be found in the same literature a POSITA would consult. KSR: "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."

---

7. Objective indicia (secondary considerations) — and the honest counterweights

Indicia that favor obviousness:

• No unexpected results. The specification claims no surprising property; each type's cryptographic treatment follows directly from who controls the key. The record shows no evidence of an unpredictable benefit.
• No nexus evidence. The patent is expired ("Expired – Fee Related," adjusted expiration 2024-08-30) and, per the Litigation and PTAB sections, was never asserted and never challenged — so there is no adjudicated commercial-success or licensing record, and no industry-praise evidence tied to these claims. Microsoft's trusted-computing program (NGSCB/"Palladium") succeeding commercially would be weak nexus evidence at best: any success is far more plausibly attributable to the platform and to the '840 architecture than to '839's classification-and-branch feature.

Counterweights a patent owner would (correctly) press, and that I must not paper over:

• Different-field risk. The cited DRM/content context is about content keys; '839 claims application secrets. A court could find the primary references (Yee, Clark/BITS, Abadi) are about hardware custody of keys generally, not about classifying application secrets for backup by migration policy.
• No single reference discloses the tripartite taxonomy. The Prior Art section said the same: "no single cited reference appears to teach selecting the wrapping key based on a migration-permission type." So the § 103 case is a combination case, and it will live or die on the strength of the motivation-to-combine showing, not on any one reference.
• Genus/species. A reference teaching a binary exportable/non-exportable distinction does not necessarily suggest a ternary taxonomy with a distinct authority (user vs. third party) for each movable class. That gap is the most likely locus of a non-obviousness finding.
• Teaching away. I found none — Schneier's key escrow and Yee's non-exportable keys are consistent with, not contrary to, the claimed scheme. So the patent owner cannot rely on a teaching-away argument from this set.

---

8. Fallback: if the granted '839 set includes the GSK/hive-key limitations

Because the full text I was given omits the claims, and because one earlier section treated these as '839's, I analyze them too — expressly labeled. If '839's granted claims recite the gatekeeper storage key sealed to a trusted core and the hive key selected by secret type and encrypted with the GSK, then the obviousness case is strong, because '839's own specification discloses these as FIG. 9–10 subject matter and the companion '840 claims them:

So the whole '840-style claim is a key hierarchy (Schneier) + sealed root bound to a measured trust anchor (Yee/AEGIS/MS apps) + a policy-selected wrapping key (the classification step). Only the last element is arguably new, and it is the same finite-solution design choice analyzed in §5–6. I flag, however, that this combination has the same "different-field / no single-reference-discloses-the-taxonomy" vulnerability described in §7.

---

9. Bottom-line per-claim assessment

Overall: Claims 2–6 and the functional claim 7 are the most exposed to a § 103 combination; the tripartite classification in independent claim 1 is the one limitation that is genuinely not cleanly taught by any single reference and is the natural center of gravity for both a validity challenge and a defense. The defensible statement is: the claimed invention is, on this record, a combination of known elements with a predictable, market-motivated policy layer, and a well-constructed § 103 challenge built on Yee + Schneier + Abadi + Clark/BITS (with Arbaugh/AEGIS and Lampson for the trust/authentication elements) has a genuine, though not overwhelming, likelihood of success. I do not find clean § 102 anticipation in this set.

---

10. What I could not verify (and what would change the analysis)

1. The exact granted claim text of '839 — the supplied full text lacked the claims section, and my tool budget for this task ended before I could pull the issued claims directly. The analysis is keyed to the pre-grant claim concepts, corroborated for the parent publication (US20030097558A1) but not confirmed against the granted set. This is the single biggest caveat, and it is why §8 is included.
2. The front-page (56) citation table for '839 — not retrievable here; the reference set is the one the Prior Art section grounded from the common-specification companion. If the granted '839 face lists art additional to this set (e.g., DRM escrow art), the § 103 case would likely strengthen.
3. Direct verification of Abadi (1992), Lampson (1992), and the Applied Cryptography page range — tool budget ended before I could re-pull them; they are carried from the Prior Art section, and I have not independently re-verified their content in this session.
4. Whether the granted '839 claims are limited to backup or also cover live migration and/or destination authentication — this changes which combinations matter (Combination A vs. A+B).

Recommended next steps: (i) pull the granted claims and the (56) block from Patent Center for application 11/068,006; (ii) confirm the Abadi/Lampson/Schneier citations; (iii) if a formal chart is the goal, treat claim 1's "type" element as the sole genuine novelty and build the motivation-to-combine showing around the closed, finite controller taxonomy (MPEP 2143 rationale (e)) plus the market-incentive evidence (rationale (f)).

No patent number has been auto-corrected; US 7,577,839 (application 11/068,006), US 7,577,840, and US 2003/0097558 A1 are each treated literally and kept distinct throughout.