US 7870399

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

Let me search specifically for litigation and docket activity.

US Patent 7,870,399 — Summary

Search scope note: I queried the open web for the patent number, for litigation, and for Federal Circuit / district-court activity. I do not have direct credentialed access to USPTO PatentCenter or PACER/CAFC docket systems, so the litigation portion below is limited to what public searches surfaced. No CAFC 2026 docket entry, complaint, or infringement action involving 7,870,399 appeared in any search result.

Bibliographic data (from the authoritative patent text)

Encumbrances (not litigation): A security agreement with Bank of America, N.A. as collateral agent (recorded 2016-05-02, reel/frame 038589/0305), with Wells Fargo Bank, N.A. recorded as successor agent on 2025-11-07 (reel/frame 073506/0385). This is a security interest in the patent, not a lawsuit.

Abstract (verbatim)

A software system that transforms an original application into an STPM enabled application and runs the enabled application. At protect time, an anti-tamper tool accepts the original application, uses anti-tamper techniques to create a guarded application, creates a security wrapper according to a policy file, and wraps the guarded application to create the STPM enabled application. A trusted service provider is inserted at the entry point of the enabled application. A set of core services is made accessible to the enabled application through the trusted service provider. At runtime the trusted service provider creates a TSP thread and passes a security file to an STPM device driver implementing TPM functionality and protected by anti-tamper techniques. The TSP thread actively monitors the enabled application and interacts with the STPM device driver through the set of core services.

Independent claims in plain language

Claim 1 — System (protect-time construction + runtime behavior).
A software system that turns an original application into an "STPM enabled application" and runs it. The system comprises five functional pieces plus a processor:

1. Anti-tamper tool — at protect time, accepts the original application and applies anti-tamper techniques to produce a guarded application.
2. Security wrapper — created at protect time by the anti-tamper tool according to a policy file that states security and usage restrictions; the wrapper wraps the guarded application to form the STPM enabled application.
3. Trusted service provider (TSP) — inserted at protect time by the anti-tamper tool at the entry point of the enabled application (i.e., it executes before the original code).
4. Set of core services — exposed to the enabled application through the trusted service provider.
5. STPM device driver — implements Trusted Platform Module functionality and is itself protected by anti-tamper techniques.
6. Processor for executing the enabled application.

Runtime limitation: the trusted service provider creates a TSP thread and passes a security file based on the policy file to the STPM device driver; that thread actively monitors the enabled application and interacts with the device driver through the core services. The core inventive hook is software-only TPM emulation (no hardware TPM required), with a protect-time wrapper/entry-point insertion plus a runtime monitoring thread.

Claim 14 — Method (protect-time transformation + runtime execution).
A method of transforming an original application into an STPM enabled application and executing it, with two phases:

Protect time:

• accept the original application and a policy file specifying security/usage restrictions;
• analyze the application with an anti-tamper tool;
• protect the application using anti-tamper techniques;
• generate a public/private key pair;
• encrypt the protected application and the policy file with the public key;
• wrap the encrypted application and policy file in a security wrapper;
• insert trusted-service-provider functionality at the entry point of the wrapped application to create the STPM enabled application.

Runtime (by a processor):

• create a trusted service provider thread;
• pass the encrypted policy file to an STPM device driver;
• decrypt the policy file and process its contents in the device driver;
• load the encrypted STPM enabled application;
• execute the application in accordance with the policy file.

Dependent claims (brief)

• 2: anti-tamper tool inserts guards and obfuscates/encrypts parts or all of the application.
• 3: device driver uses TPM hardware or other security hardware when available.
• 4: trusted service provider is standardized across a variety of STPM enabled applications.
• 5: legacy binary application; TSP embedded in the binary; policy specified in an external file enforced by the driver.
• 6: core services include content, key, credential, event, and/or audit management.
• 7: multiple enabled applications, each with its own TSP, sharing common core services.
• 8: driver accessible over a network to report system health status.
• 9: driver implements one or more of RSA keygen, RSA encrypt/decrypt, SHA-1, HMAC, RNG, internal symmetric encryption, data integrity registers, state registers, PCRs.
• 10: configurable action taken per the policy file on violation.
• 11–12: periodic integrity checks during execution, both internal and external to the application.
• 13: policy file specifies integrity verification measurements, system health requirements, runtime restrictions, licensing restrictions, and/or cryptographic keys.
• 15–17: on-demand decryption, whole-application decryption, or either depending on the policy file.
• 18: driver stores data in secure data storage registers using data splitting into N chunks, each in a separate register, computations performed independently per chunk and combined.
• 19–20: additive splitting; multiplicative splitting.

Litigation / CAFC status

No litigation or CAFC 2026 docket activity for 7,870,399 was found. Searches for "7870399" combined with "litigation," "lawsuit," "infringement," "CAFC," and "Federal Circuit," and searches pairing the named assignees (Arxan, Microsemi, Mercury) with 2026 court activity, returned no case records.

Uncertainty statement: This is a negative finding based on open-web searching only. It is not a certification that no suit, IPR/PGR, or appeal exists — PACER, the CAFC docket, and USPTO PatentCenter/PTAB are the authoritative sources and I could not query them directly in this session. If a 2026 dispute exists, it would most plausibly appear under the current listed owner (Microsemi Corp. – Security Solutions / Mercury Corp Security Solutions) rather than the original assignee Arxan Defense Systems, Inc.

I'll research litigation involving US patent 7870399. Let me run several targeted searches.

Let me verify the lead in that CAFC decision and search additional litigation databases.

The CPC v. Apple '039 patent is a different patent (US 8,620,039) — I must not conflate it with US 7,870,399. Let me search specifically for our patent number and its assignees.

Bottom line

I found no litigation involving U.S. Patent No. 7,870,399 ("Software trusted platform module and application security wrapper," assigned originally to Arxan Defense Systems, Inc.). Within the tool budget available for this run, no district court case, ITC investigation, PTAB post-grant proceeding, or Federal Circuit appeal naming US 7,870,399 could be identified.

Because the patent number 7,870,399 is sometimes informally abbreviated as "the '039 patent," I want to flag a serious false-positive risk before any case list, since your instructions require listing only results for this patent.

---

⚠️ Important disambiguation — do NOT count this case

An earlier search surfaced "the '039 patent" in active litigation. That patent is U.S. Patent No. 8,620,039, not 7,870,399:

The CPC litigation (which does not involve 7,870,399):

• CPC Patent Technologies Pty Ltd. v. Apple Inc., No. 5:22-cv-02553 (N.D. Cal.; originally 6:21-cv-00165, W.D. Tex.) — asserted US 9,665,705 and US 8,620,039. Case stayed Nov. 10, 2022 pending IPR (Doc. 146).
• IPR2022-01094 (Apple v. CPC) and the related CAFC appeal concerning claims 1, 2, 19, 20 of the '039 patent — final written decision found claims unpatentable (Sept. 18, 2023), Director Review denied Nov. 21, 2023, appealed Dec. 18, 2023.
• A parallel Australian proceeding, CPC Patent Technologies Pty Ltd v Apple Pty Limited [2025] FCA 489, on appeal (heard March 2–3, 2026, judgment reserved).
• Sources: https://storage.courtlistener.com/recap/gov.uscourts.cand.[394837](/patent/394837)/gov.uscourts.cand.394837.146.0.pdf ; https://storage.courtlistener.com/recap/gov.uscourts.cafc.21176/gov.uscourts.cafc.21176.13.0.pdf ; https://pulse.mallesons.com/ip-whiteboard/cpc-v-apple-appeal-in-funded-patent-litigation/

---

Results for US 7,870,399

Conclusion: No known litigation. On the record checked, US 7,870,399 has not been asserted in any patent infringement suit, nor has it been the subject of an IPR, PGR, CBM, or reexamination that I could locate.

What the record does show for this patent (context, not litigation)

• Prosecution/ownership history only, per https://patents.google.com/patent/US7870399/en:
  • Filed Feb. 7, 2007 (App. No. 11/672,054); granted Jan. 11, 2011; priority to provisional 60/772,370 (Feb. 10, 2006).
  • Assignment chain: Arxan Technologies (2007-03-23) → Arxan Defense Systems, Inc. (2010-11-30) → Microsemi Corp. – Security Solutions (2016-04-26, change of name) and encumbered by security interests in favor of Bank of America, N.A. as collateral agent (2016-05-02), with Wells Fargo as successor agent (2025-11-07).
  • Legal status: Active, adjusted expiration Nov. 12, 2029; maintenance fees paid at 4th, 8th, and 12th years.
• The Google Patents page contains no "Litigation" or post-grant section for this patent, and its forward-citation list consists of later patents (e.g., Mocana, Blue Cedar Networks, Digicert, HPE) rather than case records.

Confidence and limitations (stated explicitly)

• High confidence that the CPC v. Apple " '039 patent" is US 8,620,039 and is unrelated to US 7,870,399 — verified against multiple independent documents.
• Moderate confidence in the "no litigation" conclusion for US 7,870,399. This run's searches did not return a comprehensive reporter (e.g., Docket Navigator, RPX, or a full PACER docket sweep), and I reached the tool-step limit before completing queries against the Unified Patents litigation portal (https://portal.unifiedpatents.com/litigation/caselist) and the PTAB portal. I therefore cannot exclude the possibility of a lower-profile suit or an assignment-driven assertion.
• To make this airtight, the following should be checked directly: (a) Unified Patents portal search for "7870399"; (b) PACER / CourtListener docket search for "7,870,399"; (c) PTAB Patent Trial & Appeal Board search for Patent No. 7,870,399 (IPR/PGR/CBM); (d) USPTO Patent Center "Litigation" tab and the Reexamination Certificate database. Note that the current owner of record is Microsemi Corp. – Security Solutions (Arxan legacy), with a security interest held by Wells Fargo Bank, N.A. as successor collateral agent — a portfolio that, based on the records reviewed, has not been used offensively in court.

I'll search for any PTAB activity on this patent before finalizing.

Let me run a few more targeted checks before concluding.

Proceedings overview

Total AIA trial proceedings on file for US 7,870,399: zero. The structured "PTAB proceedings on file" block (sourced from the USPTO Open Data Portal) returns no IPR, PGR, or CBM proceeding, and my independent web searches turned up no PTAB proceeding, institution decision, final written decision, or Federal Circuit appeal involving this patent. Because there are no proceedings, there is no active/claims-invalidated/claims-sustained/settled/denied breakdown to give — every one of those buckets is empty.

Bottom line for a defendant: this is neither "the patent has survived IPRs and is hardened" nor "the claims are canceled and the demand letter is hollow." It is a clean-slate patent. No claim of US 7,870,399 has ever been tested at the PTAB, no claim has been canceled, and no petitioner has incurred § 315(e)(2) estoppel. The validity of claims 1–20 is untested in any AIA forum. Treat the patent as a black box: the owner gets no "PTAB-tested" halo, but you also inherit none of the evidentiary record (institution decisions, expert findings, claim-construction rulings) that a prior IPR would have handed you for free.

---

No proceedings to report

There are no PTAB proceeding numbers to list, and I will not invent any. For completeness, here is exactly what I checked and what I found:

• USPTO ODP structured data (canonical): no AIA trial proceedings.
• Web search for IPR/PGR/CBM activity tied to patent number 7,870,399 or 7870399: nothing. Results returned only aggregate PTAB statistics reports, the Google Patents / uspto.report record for the patent itself, and unrelated patents citing 7870399 as a reference.
• Web search for the assignees (Arxan Defense Systems / Arxan Technologies / Microsemi Corp. – Security Solutions): no assertion campaign or PTAB challenge surfaced in the snippets retrieved.

I was unable to complete a direct PTAB E2E / CourtListener docket pull — my search budget was exhausted before I could confirm against those databases directly. So the honest statement is: the canonical ODP list is empty and public web search corroborates it, rather than a database-by-database confirmation by me.

Patent posture (context for the empty proceeding list)

• Patent: US 7,870,399 B2 — "Software trusted platform module and application security wrapper"
• Application: 11/672,054; priority: 2006-02-10 (provisional 60/772,370); filed: 2007-02-07; granted: 2011-01-11
• Claims: 20 total. Claim 1 is an independent system claim (anti-tamper tool → security wrapper → trusted service provider → core services → STPM device driver → processor). Claim 14 is an independent method claim (protect-time transformation + runtime execution). Claims 2–13 and 15–20 are dependent.
• Claim 18 is the notable dependent claim — it recites the data-splitting-in-secure-registers limitation (N chunks, independent computation, recombination), with additive (claim 19) and multiplicative (claim 20) splitting variants. That is the claim family most likely to be the focus of any future validity fight, since the specification devotes substantial disclosure to split-computation arithmetic.
• Status: Active; adjusted expiration 2029-11-12. The patent remains in force and enforceable through that date.
• Ownership chain: Arxan Technologies → Arxan Defense Systems, Inc. (2010-09-13) → Microsemi Corp. – Security Solutions (change of name, eff. 2014-11-05); Google Patents lists current assignee as Mercury Corp Security Solutions. Encumbered by a Bank of America security agreement (2016-05-02), with Wells Fargo as successor agent (2025-11-07, eff. 2025-11-04). Practical point: you have no "operating company" counterparty symmetry argument — the patent has passed through a defense-electronics roll-up to a security-interest-encumbered holder.

---

Strategic summary

Claim status: all 20 claims UNTESTED. There is no claim of this patent that is canceled, disclaimed, or confirmed via IPR. If a demand letter or complaint asserts claims 1, 14, or 18, every one of those claims is live on paper and carries the statutory presumption of validity under § 282. Conversely, nobody has canceled any claim for you — there is no final written decision you can cite and say "this ground already won."

Estoppel landscape: a blank field. Section 315(e)(2) estoppel is created only by an instituted IPR/PGR and binds only the petitioner, RPI, and privies. Because no proceeding was ever instituted, no estoppel attaches to anyone — neither to you nor to any manufacturer, distributor, or customer upstream of you. That cuts both ways: you are free to run any § 102/§ 103/§ 112 ground you can develop, but you also cannot piggyback on a prior petitioner's work product or leverage a prior institution decision. You would be the first challenger, which means the Board has no prior record to compare against and the patent owner has had ~19 years since priority (and ~15 years since grant) to study and prepare defensive claim-construction positions.

Pattern signals: none present. There is no serial-petitioner pattern (the same petitioner filing multiple IPRs), no patent-owner PTAB-appeal pattern, and no sign of a defensive aggregator (e.g., Unified Patents) in the chain. That absence is itself informative: this patent was filed in 2007 and issued in 2011, and in ~15 years on the register it has never drawn a single AIA challenge. Either it was never commercially asserted in a way that justified the cost of an IPR, or it was asserted only where defendants chose to litigate validity in district court rather than at the PTAB. Either way, there is no public PTAB record to mine. Note that an issued patent that has sat largely dormant can be difficult to challenge under the USPTO's current "settled expectations"-style discretionary-denial practice for older patents, so if you do file, expect the institution decision — not the merits — to be the first real battle.

---

Recommended next steps

1. Do not represent to a court or adversary that any claim has been canceled. It has not. Any "the patent is invalid, it survived IPRs" framing would be false, and any "PTAB already killed claim 1" argument is sanction-bait in the opposite direction.
2. Pull the docket yourself to close the one gap I could not. Confirm the empty result directly at USPTO PTAB E2E (https://ptacts.uspto.gov/ptacts/) and CourtListener (https://www.courtlistener.com/) under both "7,870,399" and "7870399," and search for Arxan Defense Systems / Microsemi / Mercury Systems as patent-owner party names. My web-search corroboration is strong but was not a direct docket pull.
3. If you have been served with a complaint alleging infringement of 7,870,399, the clock is running. Under 35 U.S.C. § 315(b) an IPR petition must be filed within one year of service of the complaint. Compute that date immediately — it is jurisdictional in practice and the most common way defendants lose the IPR option.
4. Scope the challenge around the strongest disclosure. The specification's detailed treatment of additive and multiplicative data splitting (with the multiplication-helper construct for claim 18's "combining the results of the independent operations") is the natural locus for § 103 art. The claim-1 / claim-14 "software TPM emulating a hardware TPM" concept also invites § 103 combinations against the TCG v1.2 and TSS specifications, which the patent itself cites as the standard it complies with.
5. Check your own timing and privity. Before filing, confirm no customer, supplier, or OEM has already been served in a way that would impute § 315(b) bar or § 325(e) estoppel to you as an RPI or privy.
6. FWD/appeal links. Because no proceeding exists, there is no FWD or Federal Circuit opinion to link. If a proceeding is filed after this analysis, the FWD will appear at USPTO PTAB Decisions and any appeal at the Federal Circuit docket / CourtListener.

Bottom line: no PTAB activity on file — the absence is the finding. This patent is unvetted at the Board, unencumbered by estoppel, and fully in force until 2029-11-12. Your validity defense must be built from scratch, and your first deadline is the one-year § 315(b) bar if you have been served.

I'll research the assignment chain and ownership entities. Let me run several searches.

Let me search for the recorded correspondents and additional context.

I have the authoritative assignment events from the patent record and supporting corporate history. Two of my follow-up searches returned no usable results and one was cut off by a step limit, so a few fields (notably correspondents of record) could not be retrieved. I have flagged every such gap rather than filling it.

---

Inventors

Pattern notes.

• This is a university-spin-out inventor set: two company engineers (Bryant, Rambhia) and two academics (Atallah, and ostensibly Rice). That is the normal signature of a CERIAS-derived security software company, not the "all inventors leave the assignee within 12 months" precursor to a portfolio fire-sale that the task asks me to watch for.
• I could not retrieve inventor employment-departure data, inventor assignment-of-obligation agreements, or employment dates. Whether any inventor left within 12 months of the 2007-02-07 filing is not determinable from the sources I could reach, and I will not infer it.
• The inventors assigned their rights at Reel 019053/0595 (signing dates 2007-02-23 to 2007-03-15), i.e., roughly 2–5 weeks after filing — routine, not a distress signal.

Original assignee

Face-of-patent original assignee: Arxan Defense Systems, Inc. (per the Google Patents header and Current Assignee list). Note a subtlety the earlier summary glossed: the first recorded assignee was Arxan Technologies (Indiana), which received the inventor rights at Reel 019053/0595; title only reached Arxan Defense Systems, Inc. in 2010 (Reel 025430/0922). The two are related Arxan corporate entities.

• Business: Anti-tamper / application-protection software. Arxan Technologies is the maker of the EnforcIT® tool recited in the patent's own specification. Arxan Defense Systems, Inc. (founded 2001, West Lafayette, IN) sold application-protection and anti-tamper software to the federal/defense market.
• Product embodying the claims: Yes, plausibly — the specification names EnforcIT® as the protecting tool, and the STPM/SRT technology described is the company's core product line. I did not locate a shipping product explicitly branded "STPM," so the "embodying the claims" call is inferential.
• Current status: Acquired, and twice over. PitchBook: Arxan Defense Systems was acquired by Microsemi. Mercury Systems' own filings state Microsemi acquired Arxan Defense Systems in 2010, then Mercury acquired the "Microsemi Carve-Out Business" (including Arxan Defense Systems and White Electronic Designs) for $300M, closing ~May 2, 2016. The entity survived as a Mercury subsidiary and was renamed Microsemi Corp. – Security Solutions (see timeline).

Assignment timeline

All five recorded instruments below come from the Google Patents legal-events record for US 11/672,054, which mirrors the USPTO Assignment Center entries. Correspondents of record were not exposed by any source I could retrieve (see gaps note at the end of this section).

1. 2007-02-23 → 2007-03-15 (executed) / recorded 2007-03-23 — Reel 019053/0595

   • Conveyance: Assignment
   • Assignor: Eric D. Bryant; Avni Harilal Rambhia; Mikhael J. Atallah; John R. Rice (inventors)
   • Assignee: Arxan Technologies (Indiana)
   • Correspondent: not retrievable in this session — no recurrence claim possible.
   • Context: First-party assignment of invention rights from the inventors to the operating company at filing.

2. Executed 2010-09-13 / recorded 2010-11-30 — Reel 025430/0922

   • Conveyance: Assignment
   • Assignor: Arxan Technologies
   • Assignee: Arxan Defense Systems, Inc. (Indiana)
   • Correspondent: not retrievable in this session.
   • Context: Internal reorganization — transfer within the Arxan corporate family from the software entity to the defense-systems entity.

3. Executed 2014-11-05 / recorded 2016-04-26 — Reel 038523/0359

   • Conveyance: Change of Name (not a transfer of title)
   • Assignor: Arxan Defense Systems, Inc.
   • Assignee: Microsemi Corp. – Security Solutions
   • Correspondent: not retrievable in this session.
   • Context: Change of name only, reflecting Microsemi's 2010 acquisition and later rebranding of the acquired entity. No separate assignment to Microsemi is recorded on this patent — the name change is the only instrument evidencing Microsemi's ownership.

4. Executed/effective 2016-05-02 / recorded 2016-05-02 — Reel 038589/0305

   • Conveyance: Security Agreement (grant of security interest; title does not pass)
   • Assignors: Mercury Systems, Inc.; Mercury Defense Systems, Inc.; Microsemi Corp. – Memory and Storage Solutions; Microsemi Corp. – Security Solutions (and others)
   • Assignee: Bank of America, N.A., as collateral agent
   • Correspondent: not retrievable in this session.
   • Context: Securitization — the patent pledged as collateral under a corporate credit facility. Note this filing names both Mercury entities and both Microsemi carve-out entities in one obligor group, which independently corroborates that the Microsemi carve-out entities sat inside the Mercury corporate family as of May 2016.

5. Executed 2025-11-04 / recorded 2025-11-07 — Reel 073506/0385

   • Conveyance: Notice of Successor Agent / Assignment of Security Interest (Reel/Frame 038589/0305)
   • Assignor: Bank of America, N.A. (predecessor agent)
   • Assignee: Wells Fargo Bank, National Association (successor agent)
   • Correspondent: not retrievable in this session.
   • Context: Securitization only — substitution of collateral agent on the existing lien; no change in patent ownership.

Critical gap — correspondents. The task's central evidentiary lever is the correspondent of record (the attorney/firm that filed each recording). Neither the Google Patents legal-events mirror nor any open-web source I reached discloses it, and my direct-quote searches on the reel/frame numbers ("019053/0595", "025430/0922", "038523/0359") returned no results. The USPTO Assignment Center record for each reel/frame would expose it, but I could not query that system directly in this session. I therefore make no correspondent-recurrence finding — asserting one would be fabrication.

Critical discrepancy to flag against the earlier summary. The prior summary stated the current assignee is "Mercury Corp Security Solutions" and characterized the 2016-04-26 filing as a "change of name from Arxan Defense Systems, Inc. to Microsemi Corp. – Security Solutions." That is accurate for Reel 038523/0359, but it conflates the recorded legal owner with the Google-derived header label. The last title-affecting instrument of record is the 2014-11-05 change of name to "Microsemi Corp. – Security Solutions." I found no recorded assignment of this patent to Mercury Systems, Inc. or to any "Mercury Corp Security Solutions" entity. The Google header's "Mercury Corp Security Solutions" is best explained by the May 2016 Mercury carve-out acquisition (asset/stock) plus a later corporate renaming, but that transfer does not appear as a recorded assignment on this patent. This is a genuine record-chain gap worth verifying in Assignment Center. (The earlier summary's "US 77/237,006" was also a garbled rendition of provisional 60/772,370.)

Timeline diagram

timeline
    title Ownership of US 7870399
    2006 : Provisional 60772370 filed
    2007 : Application 11672054 filed
    2007 : Inventors assign to Arxan Technologies
    2010 : Assigned to Arxan Defense Systems
    2011 : Patent US 7870399 issued
    2014 : Renamed Microsemi Corp Security Solutions
    2016 : Mercury buys Microsemi carve out
    2016 : Bank of America security agreement
    2025 : Wells Fargo becomes successor agent

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT. Every assignee in Reels 019053/0595, 025430/0922, and 038523/0359 is an operating company: Arxan Technologies (product: EnforcIT®), Arxan Defense Systems (defense anti-tamper software), and Microsemi Corp. (public semiconductor company). No "IP / Holdings / Ventures / Licensing" suffix appears anywhere in the chain, and no single-purpose Delaware or Texas LLC is present.

2. Known asserter in the chain — NOT PRESENT. None of the enumerated NPE directories (Acacia, Marathon, IV, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, Spangenberg entities) appears. Reels 038589/0305 and 073506/0385 involve Bank of America and Wells Fargo — lenders, not asserters.

3. Repeat correspondent across the chain — UNCLEAR / NOT DETERMINABLE. Five reel/frame entries exist, but no correspondent name was exposed by any source I could access, and targeted searches on the reel/frame strings returned nothing. I cannot confirm or deny recurrence. This is the single highest-value unresolved field; verify directly in Assignment Center.

4. Cascading transfers — NOT PRESENT. Only two title-affecting assignments exist across ~16 years (Reels 019053/0595 in 2007 and 025430/0922 in 2010), and both are within the same corporate family. There is no <24-month chain through unrelated assignees.

5. Pre-litigation transfer — NOT PRESENT. No infringement suit naming this patent was found in open-web searching, so no assignment can be measured against a suit date. The most recent title-affecting instrument (Reel 038523/0359, executed 2014-11-05) predates any hypothetical assertion by over a decade.

6. Bankruptcy fire-sale — NOT PRESENT. No Chapter 7/11 for any assignor appears in the chain. Microsemi was later acquired by Microchip Technology (2018), but that is a parent-level M&A event affecting a company that had already divested this entity to Mercury in 2016; it is not a bankruptcy sale of this patent. Mercury Systems remains an operating, publicly traded company (NASDAQ: MRCY).

7. Privateering — NOT PRESENT. No operating-company→NPE transfer, and no SEC-disclosed or press-reported assertion arrangement involving this patent. The 2016 carve-out was a business-line divestiture for $300M, in which the acquirer inherited the acquirer's own products and customers — the opposite of privateering.

8. Defensive aggregator — NOT PRESENT. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. Current ownership is an operating defense contractor.

Encumbrance (not an NPE signal): Reel 038589/0305 and Reel 073506/0385 are liens/secured-financing instruments. They encumber the patent but do not transfer title and are not a transfer-to-asserter event.

Verdict

Operating-company assertion — with an explicit caveat on the "assertion" prong.

Justification: The chain is a clean, four-decade-typical operating-company chain — inventors→Arxan Technologies at Reel 019053/0595 (2007), intra-family transfer to Arxan Defense Systems at Reel 025430/0922 (2010), and a pure change of name to Microsemi Corp. – Security Solutions at Reel 038523/0359 (executed 2014-11-05) after Microsemi's 2010 acquisition. It ends (absent the unrecorded Mercury carve-out) inside a publicly traded aerospace-and-defense contractor that ships anti-tamper security products, with the patent merely pledged as loan collateral at Reels 038589/0305 and 073506/0385. All eight NPE signals are absent or undeterminable; not one is present, which rules out the NPE verdicts. The caveat: the enumerated "operating-company assertion" category presumes the owner is suing competitors, and I found no suit involving US 7,870,399. So read this verdict as "operating-company ownership, non-asserting so far," and note that if the missing Mercury-to-entity assignment were found to run through a holding structure, or if the reconveyed entity ever asserts, this call would need revisiting.

Verification links: USPTO Assignment Center — https://assignmentcenter.uspto.gov/ ; legacy Assignment Search by patent number — https://assignment.uspto.gov/patent/index.html (query "7870399" to pull Reels 019053/0595, 025430/0922, 038523/0359, 038589/0305, 073506/0385 and their correspondents of record).

Limitations: I do not have credentialed access to Assignment Center, PACER, or PTAB, and two of my final searches returned zero results while a third was cut off. The correspondent-of-record fields, the existence of any unrecorded Mercury carve-out assignment, and any litigation are therefore unverified, and my findings are negative findings only.

I'll search the USPTO/public databases for US 7,870,399 and its cited prior art, then analyze each citation against the claims.

I found search results referencing two things worth flagging: a PTAB petition and an EDTX case both referring to a "'399 Patent" whose claim terms ("tamper resistant key module," "trusted player") don't match US 7,870,399. Let me investigate that discrepancy and verify a few key references.

Confirmed an important disambiguation: the "'399 Patent" in the Plano Encryption Technologies litigation and the IPR2017-01783 docket is U.S. Patent No. 5,991,399 ("tamper resistant key module"/"trusted player"), not US 7,870,399. Let me verify two more citation details and check for any post-grant challenge to 7,870,399 itself.

Prior-Art Analysis for US Patent 7,870,399

Analyst note on search scope. I searched for the specific number 7870399 across public mirrors of USPTO data (Google Patents, uspto.report, PTAB PTACTS, Justia dockets, FreePatentsOnline). I do not have credentialed PatentCenter/PTAB/PACER access in this session, so the citation inventory below is taken from the authoritative full patent text supplied in this task (the USPTO-derived "Patent Citations (35)" and "Non-Patent Citations (8)" lists), and I used web search only to verify individual reference details. Nothing below should be read as a legal opinion or a validity conclusion.

---

1. Patent identification — confirmed, with two flags

US 7,870,399 B2, Software trusted platform module and application security wrapper, App. 11/672,054, filed 2007-02-07, priority 2006-02-10 (prov. 60/772,370), granted 2011-01-11, 20 claims (independent 1 and 14). This matches the authoritative text and the prior section; I do not repeat the bibliographic summary.

Flag A — a genuine "’399" collision in the search results (important, and it supports the earlier negative litigation finding). My searches surfaced a "'399 Patent" in:

• Plano Encryption Technologies, LLC v. American Bank of Texas, No. 2:15-cv-01273-JRG-RSP (E.D. Tex.), and
• IPR2017-01783 (PTAB), and a companion petition involving U.S. Pat. 5,974,550.

Those documents construe "tamper resistant key module," "trusted player," "manifest parser generator code," and cite Aucsmith's IVKs and U.S. Pat. 5,892,899. The claims at issue read: "generating an asymmetric key pair… encrypting predetermined data with the generated public key… building an executable tamper resistant key module…" — which is the claim set of U.S. Patent No. 5,991,399 ("Secure distribution of a private key… trusted player," Plano Encryption Technologies). That is a different patent. So the earlier section's conclusion — no litigation found for 7,870,399 — stands, and the ambiguity is explained: keyword searches for "399 Patent" in 2015–2017 dockets return 5,991,399, not 7,870,399. I did not find any IPR/PGR, reexam, or district-court action naming 7,870,399.

Flag B — identifier inconsistency in the earlier generated summary. That section listed the related family as "provisional US 77/237,006 (i.e., US 60/772,370)." The authoritative text shows only two priority members: US 60/772,370 (provisional, 2006-02-10) and US 11/672,054. The string "77/237,006" does not correspond to any U.S. series shown in the text and appears to be a transcription artifact. I flag it rather than auto-correct it; per the operating rule, I treat 60/772,370 as the literal provisional number.

---

2. Framework for the §102 assessment

The application was filed 2007-02-07 with a 2006-02-10 priority date, so pre-AIA 35 U.S.C. §102 governs. Anticipation under §102 requires every element of a claim in a single reference, arranged as claimed. My honest assessment: no single cited reference anticipates independent claim 1 or claim 14 in their entirety. The claims combine (i) software-only TPM emulation, (ii) protect-time anti-tamper wrapping plus entry-point insertion of a trusted service provider bound to a policy file, and (iii) a runtime monitoring thread that passes the policy file to the driver through core services. The cited art divides cleanly along those three axes, which is why this is overwhelmingly a §103 case built from two- and three-reference combinations, with §102 attacks confined to narrow dependent claims (notably claims 9 and 18–20).

Below, "§102" gives any claim I believe the reference could potentially anticipate standing alone; "§103 target" gives the claims it most naturally attacks in combination.

---

3. The 35 cited patent references

Dates are as printed in the authoritative citation table (priority/filing date → publication date where a pre-grant publication is cited).

Tier 1 — Software/virtual TPM (attacks the core of claims 1, 3, 9)

1. US 2006/0020781 A1 — Scarlata & Rozas (Intel), "Method and apparatus for providing secure virtualization of a trusted platform module" — filed 2004-06-24; pub. 2006-01-26; granted as US 7,590,867 B2 (2009-09-15).
Description: A virtual TPM service (GVTPM framework) creates virtual TPMs that are "a logical (i.e., primarily software-implemented) component that provides TPM-like functionality." Discloses a fully software-based device model in which "all virtual PCRs, monotonic counters, non-volatile storage, and other TPM resources are stored and managed in the memory of the device model," with vEK/vSRK/vPCRs/vDIRs emulating hardware TPM structures, plus a "TPM device" and "TPM driver" in the architecture.
§102: No anticipation in full of claim 1 or 14 — it contains no anti-tamper tool, no protect-time security wrapper around an application, no trusted service provider inserted at an application's entry point, and no policy file passed to a driver at runtime. Its claim-9 elements (RSA, SHA-1, HMAC, RNG, symmetric encryption, DIRs, PCRs) are, however, substantially all present → potential §102(e) as to claim 9; the strongest single §103 reference against claims 1, 3, 9.

2. US 2007/0079120 A1 — Bade, Berger, Goldman, Perez, Sailer, Van Doorn (IBM), "Dynamic creation and hierarchical organization of trusted platform modules" — filed 2005-10-03; pub. 2007-04-05; granted as US 8,549,288 B2. (Verified: continuation of 11/242,673, filed 2005-10-03.)
Description: A TPM capable of dynamically creating multiple virtual TPMs in software ("virtual TPM functionality as software in the TPM domain"), each vTPM associated with a logical partition/OS, with TPM command routing and PCR-based attestation.
§102: Published after the '399 filing but qualifies as §102(e) art as of its 2005-10-03 filing date. Anticipates no full claim; relevant to claim 1 (software TPM) and claim 7 (multiple applications/instances sharing common services) under §103.

3. US 2005/0246521 A1 — Bade et al. (IBM), "Method and system for providing a trusted platform module in a hypervisor environment" — filed 2004-04-29; pub. 2005-11-03; parent granted as US 7,484/8,086,852. (Verified via US 8,086,852, which continues Ser. No. 10/835,350 filed 2004-04-29.)
Description: A hypervisor reserves a partition for a hypervisor-based TPM (HTPM) presented to other partitions "as a virtual device via a device interface," and instantiates logical TPMs anchored to the HTPM, each associated with a logical partition. Explicitly notes hardware TPMs are "not available for virtualizeable platforms," motivating software instantiation.
§102: No full anticipation; §102(e)/§103 as to claims 1, 3, 9 (software TPM instantiated as a device/driver, per-partition anchoring).

4. US 2005/0138370 A1 — Goud et al. (Intel), "Method and system to support a trusted set of operational environments using emulated trusted hardware" — filed 2003-12-23; pub. 2005-06-23.
Description: Support of a trusted set of operational environments using emulated trusted hardware — i.e., TPM-like services without a dedicated physical TPM per environment.
§102: Closest to claim 3 (use of TPM/other security hardware "when available") and the software-emulation premise of claim 1; no full anticipation → §103 on claims 1, 3, 9.

5. US 2006/0053302 A1 — Fujitsu, "Information processing apparatus with security module" — filed 2004-09-07; pub. 2006-03-09.
Description: Security module in an information processing apparatus providing protected cryptographic processing/storage.
§102: No full anticipation; §102(e)/§103 as to claims 1, 3, 9 (device-driver-level security module implementing cryptographic services).

6. US 2005/0086509 A1 — Ranganathan (IBM), "Extended trusted computing base" — filed 2003-10-17; pub. 2005-04-21.
Description: Extending the trusted computing base to encompass additional security services beyond the hardware core.
§102: No full anticipation; §103 as to claim 1 (software extension of TCB/root of trust).

Tier 2 — Anti-tamper, guards, obfuscation, policy enforcement (attacks claims 2, 10–13)

7. US 2006/0031686 A1 — Atallah & Chang (Purdue Research Foundation), "Method and system for tamperproofing software" — pub. 2006-02-09; filed 2005-07-27 (Ser. No. 11/190,475), continuation of Ser. No. 09/455,580 (1999-12-06), prov. 60/152,769 (1999-09-03); granted US 7,757,097 B2. (Verified.)
Description: Obfuscation (CFG merging/cloning, data-aliasing), distributed networks of guards that checksum code blocks and take delayed defensive action, patching of binary images, guard-formation graphs.
§102: No — and a caveat worth flagging: Mikhail J. Atallah is a named co-inventor of 7,870,399, and the reference is his own earlier work (published 2006-02-09, one day before the '399 priority date, and less than one year before the '399 filing). Pre-AIA §102(a)/(e) require the reference to be "by another," so common inventorship may disqualify this reference as §102 art. Treat it as high-relevance technical background for claims 2, 11, 12 (guards, obfuscation), not as clean anticipatory art.

8. US 2006/0101047 A1 — Rice, "Method and system for fortifying software" — filed 2004-07-29; pub. 2006-05-11; this is application Ser. No. 11/192,886, which 7,870,399 expressly incorporates by reference ("fortified software concept").
Description: Fortification/guarding of software, guard networks, integrity verification.
§102: Because it is incorporated by reference into the '399 specification, it is best treated as part of the disclosure, not as separate prior art. Note the same common-inventor caveat: John R. Rice is a co-inventor of 7,870,399. If treated as art, it targets claims 2, 11, 12.

9. US 4,850,019 A — Nippon Telegraph & Telephone, "Data randomization equipment" — 1985-11-08 / 1989-07-18.
Description: Hardware/software randomization (splitting/permuting) of data for cryptographic protection.
§102: No full anticipation; §103 as to claims 18–19 (data splitting/randomization as the obfuscation mechanism for stored state).

10. US 5,727,062 A — Ritter, "Variable size block ciphers" — 1995-07-06 / 1998-03-10. §102: none; §103 as to claim 2 (obfuscation/encryption of code).

11. US 5,757,909 A — LG Electronics, "Illegal view and copy protection method in digital video system and controlling method thereof" — 1994-11-26 / 1998-05-26. §102: none; §103 as to claims 10, 13 (usage restrictions, licensing/keys).

12. US 6,011,849 A — Syndata Technologies, "Encryption-based selection system for steganography" — 1997-08-28 / 2000-01-04. §102: none; §103 as to claim 2.

13. US 6,766,063 B1 — NTT, "Data converter…" — 1998-01-27 / 2004-07-27, and US 6,995,692 B2 — Matsushita, "Data converter and method thereof" — 2003-10-14 / 2006-02-07.
Description: Data conversion/transform techniques (obfuscatory data representation).
§102: none; §103 as to claim 2 (obfuscation/protection transforms applied to code and data).

14. US 2005/0147244 A1 — Moldovyan, "Method for cryptographic transformation of binary data blocks" — 2003-12-30 / 2005-07-07. §102: none; §103 as to claim 2.

15. US 2005/0036617 A1 — Cheng, "Crypto-engine for cryptographic processing of data" — 2003-08-15 / 2005-02-17. §102: none; §103 as to claims 6, 9 (crypto-engine services exposed through an API).

16. US 6,925,562 B2 — IBM, "Scheme for blocking the use of lost or stolen network-connectable computer systems" — 1999-12-17 / 2005-08-02. §102: none; §103 as to claims 10, 13 (configurable enforcement actions driven by an external policy/authority).

17. US 2005/0060568 A1 — Beresnevichiene (IBM), "Controlling access to data" — 2003-07-31 / 2005-03-17, and US 2005/0060561 A1 — Pearson (IBM), "Protection of data" — 2003-07-31 / 2005-03-17.
Description: Policy-driven control of access to protected/encrypted data at runtime.
§102: none; §103 as to claims 10 and 13 (policy file specifying restrictions; enforcement action on violation). These two are the closest policy-file analogies in the cited set.

18. US 2003/0110372 A1 — Proudler (HP), "Information security system" — 2001-04-24 / 2003-06-12; US 2005/0223221 A1 — Proudler, "Apparatus and method for creating a trusted environment" — 2001-11-22 / 2005-10-06; and EP 1 076 279 A1 — Hewlett-Packard, "Computer platforms and their methods of operation" — 1999-08-13 / 2001-02-14.
Description: Foundational trusted-platform (pre-TCG/TCPA) disclosures: a trusted computing platform with a trusted device, integrity metrics of platform state, and creation of a trusted environment verified before use.
§102: EP 1 076 279 A1 is the most structurally interesting of the three and the best candidate for a §102 attack on narrow parts of claim 1/3, but it lacks the software STPM device driver, the security wrapper, and the TSP thread. Treat all three as §103 art against claims 1, 3, 8, 11–13 (platform attestation and integrity measurement).

19. US 2005/0138384 A1 — Brickell (Intel), "Attesting to platform configuration" — 2003-12-22 / 2005-06-23. §102: none; §103 as to claims 8, 11, 12, 13 (integrity measurement and remote reporting of platform state).

20. WO 2005/033914 A1 — Koninklijke Philips, "Method of and circuit for identifying and/or verifying hardware and/or software of an appliance…" — 2003-10-06 / 2005-04-14. §102: none; §103 as to claims 1, 3, 11 (verifying the integrity/identity of software and hardware modules).

21. US 2006/0053277 A1 — Wang, "System and method for remote security enablement" — 2004-09-08 / 2006-03-09. §102: none; §102(e)/§103 as to claims 8, 10 (network-side security enablement / health reporting).

22. US 6,834,342 B2 — Eecad, "Secure communication over unstable public connections" — 2000-08-16 / 2004-12-21; US 7,000,105 B2 — Identrus, "Certificate validation…" — 2000-09-08 / 2006-02-14; US 2003/0231765 A1 — Broadcom, "Authentication and decryption" — 2002-05-31 / 2003-12-18.
§102: none; §103 as to claims 6, 13 (credential/key management and certificate validation as core services). Note the Identrus patent issued 2006-02-14, four days after the '399 priority date, but is §102(e) art as of its 2000-09-08 filing.

Tier 3 — Data splitting / secure storage (attacks claims 18–20)

23. EP 0 869 635 A2 — Hitachi, "Encrypted data recovery method using split storage key and system thereof" — 1997-03-31 / 1998-10-07. Description: A storage key split across locations for recovery. §102: none (it is a key-recovery scheme, not computation on split data); §103 as to claims 18–19.

24. US 2004/0049687 A1 — Orsini (Security First Corp.), "Secure data parser method and system" — 1999-09-20 / 2004-03-11, and US 6,853,988 B1 — Security First Corp., "Cryptographic server with provisions for interoperability between cryptographic systems" — 1999-09-20 / 2005-02-08.
Description: Parsing/splitting data into multiple shares and cryptographically servicing them.
§102: none in full (neither stores shares "in separate secure data registers" of a TPM-emulating driver, nor combines independent per-chunk results); §103 as to claims 18, 19, 20 — and see the argument in §4 below.

25. US 2005/0237821 A1 — Dekker, "Method and system of external data storage" — 2004-02-12 / 2005-10-27; US 2006/0015946 A1 — Hitachi, "Method and apparatus for secure data mirroring a storage system" — 2004-07-16 / 2006-01-19.
§102: none; §103 as to claims 18–20 (distributed/split protected storage of state).

Tier 4 — Application-level encryption and protection of executables (attacks claim 14)

26. US 6,976,166 B2 — Hewlett-Packard, "Method and apparatus for partial encryption of content" — 2001-02-06 / 2005-12-13.
Description: Partial (on-demand) encryption/decryption of content rather than whole-file processing.
§102: none in full; this is the most on-point cited reference for claims 15 and 16 (decrypt on demand vs. decrypt in entirety) → §103, and worth noting as the closest thing to an anticipation of claim 15 standing alone (though claim 15 depends on claim 14's full protect-time/runtime sequence).

27. US 2005/0229008 A1 — Hewlett-Packard, "Method and device for identifying user-selected equipment" — 2004-04-07 / 2005-10-13. §102: none; §103 as to claim 13 (licensing/binding restrictions tied to identified equipment).

---

4. The eight non-patent citations

---

5. Bottom line

No cited reference, alone, anticipates independent claim 1 or claim 14. The three elements that defeat every single-reference attack are: (1) the protect-time anti-tamper tool + policy-file-driven security wrapper around an application (not a VM/partition), (2) trusted-service-provider code inserted at the application's entry point and executing first, and (3) the runtime TSP thread that passes the policy/security file to a kernel-mode STPM device driver through core services while actively monitoring the application. The cited corpus supplies (i) software/virtual TPMs (Scarlata, Bade ×2, Goud, Fujitsu) without the wrapper/TSP layer; (ii) anti-tamper wrappers and guard networks (Atallah/Purdue, Rice/Arxan, Philips, HP) without TPM emulation; and (iii) data splitting (Orsini, Security First, Hitachi EP, NTT) without either.

Where §102 is genuinely arguable, it is narrow:

• Claim 9 vs. TCG "TPM Main: Part 1 — Design Principles," Feb. 13, 2005 (the operation list), and to a lesser degree vs. US 2006/0020781 A1 (Scarlata) under §102(e).
• Claim 6 vs. TCG TSS Part 1, Jan. 6, 2006 (the "core services" enumeration).
• Claims 15/16 vs. US 6,976,166 B2 (HP partial encryption) — but only if claim 15's dependency on claim 14 is overcome, which it is not on this record.
• Claims 18–20 vs. US 2004/0049687 A1 / US 6,853,988 B1 (Security First) and EP 0 869 635 A2 (Hitachi) in combination with a TPM-emulating driver under §103.

Most likely §103 combinations (for a challenger): Scarlata US 2006/0020781 (software TPM) + Atallah US 2006/0031686 or Rice US 2006/0101047 (guards/obfuscation/wrapper) + TCG TSS (core services), optionally + Orsini/Security First (data splitting) and US 6,976,166 (partial decryption). The principal defenses are (a) the common-inventorship/"by another" challenge to the two Arxan- and Purdue-linked references (both name co-inventors of 7,870,399), and (b) the absence in the art of entry-point TSP insertion bound to a policy file and passed at runtime to a kernel STPM driver.

Uncertainty statement. I could not query USPTO PatentCenter, PTAB (other than via the public PTACTS document links returned by search), or PACER/CAFC directly. The citation inventory is authoritative as supplied; my characterizations of individual references rely on the cited publications' own texts and public bibliographic records and are stated with the confidence levels indicated. Nothing here is a legal conclusion as to validity, infringement, or the status of any proceeding, and the "§102/§103" designations are analytical judgments for prioritization, not findings.

I'll ground the analysis in the specific prior-art references listed on the patent page. Let me verify the subject matter of the key references before combining them.

Obviousness Analysis — US 7,870,399 B2 under 35 U.S.C. § 103

Scope note: This analysis is built exclusively from the reference list printed on the face of US 7,870,399 (35 patent citations + 8 non-patent citations), supplemented by verification of the subject matter of the key references via public sources. It is analytical only, not legal advice or a validity opinion. Claim construction of terms such as "STPM enabled application," "security file based on the policy file," and "guard" would materially affect the result.

Contradiction flagged from the prior section: The earlier summary stated the provisional as "US 77/237,006 (i.e., US 60/772,370)." The authoritative text says only Provisional Application Ser. No. 60/772,370, filed 2006-02-10, "Software Root of Trust." There is no 77/237,006 in the record. That earlier line appears garbled and should not be relied on.

---

1. Graham factor 1 — Scope and content of the prior art

Every reference on the face of the patent predates the 2006-02-10 priority date, with one timing caveat discussed below. The art clusters into four groups that map almost one-to-one onto the elements of the two independent claims.

Group A — Software/emulated TPM (defeats the "no hardware TPM" core of claim 1)

Group B — TCG standards (supply the "trusted service provider + core services" architecture and the required TPM algorithm set)

• TCG, "TPM Main: Part 1 Design Principles," Spec v1.2 rev. 85, Feb. 13, 2005 — defines PCRs, DIRs, RSA keygen/encrypt-decrypt, SHA-1, HMAC, RNG, and the "shielded location" / "protected capability" concepts the patent quotes verbatim.
• TCG, "TCG Software Stack (TSS): Part 1 Commands and Structures," Spec v1.2 Level 1, Jan. 6, 2006 — defines the TSS layering, i.e., the service-provider-to-core-services arrangement recited in claim 1.
• TCG, "Embedded Systems and Trusted Computing Security," Sep. 14, 2005; TCG, "TPMs Strengthen User and Platform Authenticity," Jan. 2005.

The applicant concedes these are the blueprint: "The TCG Core Services implementation details can be found in the TCG specification for the Trusted Software Stack (TSS)" and "All of the STPM components are compliant with the standards set forth by the [TCG]."

Group C — Anti-tamper / fortification / guards (supply the anti-tamper tool, the wrapper, and the monitoring thread)

• US 2006/0101047 A1 (Rice, Arxan), priority 2004-07-29 → pub. 2006-05-11: networks of internal and external guards, secure identities for dynamic identification, components that protect each other, and "explicit policies that determine the fortification and establish the system relationships." Guards "continually check the program during its execution," detect tampering, and take responses. Timing: this published after the 2006-02-10 priority date but before the 2007-02-07 filing, so it is §102(e) prior art as of its 2004-07-29 U.S. filing date; it is also incorporated by reference into the '399 specification (Ser. No. 11/192,886).
• US 2006/0031686 A1 (Purdue Research Foundation) "Method and system for tamperproofing software," priority 1999-09-03.
• Atallah et al., "A Survey of Anti-Tamper Technologies," CrossTalk, Nov. 2004 — surveys obfuscation, guarding, and tamper-proofing.
• Applicant's own incorporated applications, cited in the '399 specification: Ser. No. 10/809,155 ("System and Method for Inserting Security Mechanisms into a Software Program"), Ser. No. 11/178,710 ("Combination Guards"), US 6,941,463 and US 6,957,341 (secure computational outsourcing).

Group D — Data splitting / secret sharing (supports claims 18–20)

• US 2004/0049687 A1 (Orsini et al.; Security First), filed 2003-06-11 → US 7,391,865: a secure data parser that "parses data and then splits the data into multiple portions that are stored or communicated distinctly." Teaches "cryptosplit partitions the data into N number of shares"; XOR/One-Time-Pad splitting where the secret s is split into a and b with s = a XOR b, "the values a and b are referred to as shares or portions and are placed in separate depositories"; states compromise of an individual facility yields "only a randomized undecipherable number."
• US 4,850,019 (NTT, data randomization), EP 0 869 635 A2 (Hitachi, "Encrypted data recovery method using split storage key"), US 6,769,063 B1 (NTT) and US 6,995,692 B2 (Matsushita) (data converters).
• Denning & Smid, "Key Escrowing Today," IEEE Comms Mag., Sep. 1994; Blum, "How to Exchange (Secret) Keys," ACM TOCS, May 1983.
• US 6,976,166 B2 (HP) "Method and apparatus for partial encryption of content" (2001-02-06) — supports selective/on-demand decryption.

---

2. Graham factor 2 — Differences between the claims and the prior art

The '399 claims are, structurally, an assembly of the four groups above:

The only elements for which no single reference is a clean anticipation are the particular sequencing of (i) protect-time entry-point TSP insertion and (ii) runtime hand-off of a policy-derived file to a kernel-mode driver. That is a combination question, not a novelty question, and is addressed below.

---

3. Combination analyses — why a PHOSITA would have combined these references

Combination 1 (primary) — Scarlata '781 + Rice '047 + TCG TSS NPL → claims 1 and 14

• Scarlata supplies every "TPM functionality" limitation in software, including a vTPM with vPCRs/vDIRs/EK/SRK, and expressly contemplates the emulator residing in "firmware or any other protected environment." Goud '370 supplies the same in even more explicit terms ("emulate a trusted platform module to execute trusted operations").
• Rice '047 supplies the anti-tamper tool, the guarded application, and guards that "continually check the program during its execution" and take configurable protective action upon detecting tampering — i.e., the claimed wrapper, guards, and the runtime-monitoring TSP thread. Rice also supplies the "explicit policies" that govern the fortification.
• TCG TSS (Jan. 6, 2006) supplies the "trusted service provider" and "core services" abstraction, which the patent itself concedes is the TCG-standard arrangement.

Motivation (articulated reasons, KSR-consistent):

1. Same field, same problem. Both Scarlata and the '399 patent address delivering TPM services where a hardware TPM is absent or unavailable. Scarlata's stated driver is supporting TPM services for virtual machines; Goud's is that "widespread acceptance and implementation of the TCG architecture and the TPM is still uncertain"; Bade's is that "Currently, TPMs are not available for virtualizeable platforms."
2. Self-evident necessity of protecting the software TPM. Once TPM functionality is moved into software, the software becomes the root of trust. Rice's guards exist precisely to make a software component resist tampering and spoofing. A PHOSITA implementing a software TPM would have had a strong reason to protect it using the known guard/obfuscation/anti-debug toolkit, and the '399 patent says as much about its own driver: it "acts as the root of trust when no hardware TPM is available."
3. The applicant's own admitted design space. The '399 background states the very need the combination satisfies: "a need exists for a software system that can provide a similar set of features as those offered by hardware TPMs, but without requiring the presence of a hardware TPM device," and "an automated protection mechanism to securely insert TPM hooking functionality into legacy applications without dependence on source code." A recitation of a need, followed by the predictable assembly of known elements that meet it, is the classic KSR fact pattern.
4. Standards compulsion. Where the TCG TSS specification defines the service-provider/core-services layering, following that specification is not an inventive act but a compliance requirement — the '399 specification admits full compliance.

Combination 2 (alternative primary) — HP Proudler/EP 1 076 279 + Scarlata '781 + Rice '047

HP's trusted-platform references teach creating a trusted environment in platform software and an information security system reachable by applications; Scarlata supplies software TPM emulation; Rice supplies fortification. The motivation is the same as Combination 1, with the added HP teaching that the "shielded location" can be a logical/software construct — which is exactly the '399 framing ("logically protected form," "software-created shielded location").

Combination 3 — Combination 1 + HP '166 (partial encryption) + Orsini '687 → claim 14, claims 15–17

Claim 14 adds: generate a public/private key pair; encrypt the protected application and the policy file with the public key; wrap; and at runtime pass the encrypted policy file to the driver, decrypt it, and load/decrypt the application either on-demand or all-at-once depending on the policy file.

• HP US 6,976,166 B2 teaches partial encryption of content and selective decryption — mapping directly onto claims 15–17's on-demand vs. whole-application alternatives.
• Orsini '687 teaches encrypting with a public key, splitting/storing key material separately, and reconstructing with a private key.
• Motivation: encrypting an executable to gate its execution and to control licensing is the standard commercial mechanism in this field; the '399 specification's own policy-file contents (licensing counts, expiration, decryption keys) are ordinary license-management features that Rice's "explicit policies" already anticipate.

Combination 4 — Orsini '687 + US 4,850,019 + EP 0 869 635 + Denning & Smid → claims 18–20

Claim 18 recites splitting data into N chunks, storing each chunk in a separate secure data register, operating on each chunk independently, and combining results. Orsini '687 discloses nearly this verbatim in the cryptographic-splitting sense (N shares, separate storage locations, individually useless shares, XOR/OTP splitting in the additive case, and key splitting for the multiplicative case). US 4,850,019 and EP 0 869 635 add separate storage of split key material; Denning & Smid and Blum add the theoretical justification.

Motivation: the '399 specification states the motivation itself — data is split so that "the attacker must compromise all N chunks… to determine the value of the original data" and "to make tampering more difficult by keeping the data in a logically protected form." Orsini articulates the identical motivation ("compromise of an individual data storage facility produces only a randomized undecipherable number"). When the prior art supplies both the technique and the same stated reason for using it, the combination is strongly obvious.

Notably, the '399 specification cites the secure-multiparty-computation literature and distinguishes it only on performance and generality grounds ("it cannot afford to do the above-mentioned circuit simulations because that would be too slow"; "it needs to securely mimic a general purpose computer"). Those are optimization arguments, not differences in kind, and the specification's detailed recitation of additive splitting, multiplication with helpers H₁/H₂, XOR, complement, and conditional branching reads as a straightforward engineering adaptation of known SMC primitives.

---

4. Claim-by-claim summary

---

5. The strongest counterarguments a patent owner would raise (candid assessment)

1. The "tight binding" theory. The '399 specification emphasizes that guards invoke the TSP thread "to tightly bind the TSP security thread, the STPM-enabled application 12, and the device driver 22 together." No single reference in the list is a clean teaching of three-way mutual binding among app, in-process thread, and kernel driver. A patent owner would argue this is a specific architecture, not a mere aggregation. A rebuttal is available (Rice's mutual-protection guard network plus a TSS-provided service provider naturally yields the same topology), but the point is genuine.
2. Register-level data splitting. Claims 18–20 recite splitting into "secure data storage registers" (SR/DIR/PCR), not generic shares or depository locations. Orsini splits data across storage facilities; the assertion that a PHOSITA would move the same technique inside the TPM's registers would have to be supported by art showing register-internal obfuscation. The '399 specification's own performance argument (SMC circuit simulation is "too slow" for general-purpose computation) is at least a technical differentiator that could support non-obviousness of the specific operation-by-operation split arithmetic.
3. Secondary considerations. No evidence of unexpected results appears in the text supplied. Commercial success (Arxan's EnforcIT/GuardIT lineage, the Microsemi/Mercury acquisitions) could be proffered, but nexus to these claims — rather than to the incorporated guard patents — would be the contested battleground.
4. Timing caveat. Rice US 2006/0101047 post-dates the 2006-02-10 priority date. Its availability as §103 prior art depends on (a) its 2004-07-29 filing date for §102(e), and (b) the scope of §112 support the provisional 60/772,370 provides for the challenged claims, since a provisional-supported claim gets the earlier date for the invention but not for intervening §102(e) art under pre-AIA practice. This should be checked against the file wrapper before relying on Rice as the primary anti-tamper reference. The applicant's incorporation by reference of the same fortifying-software work (Ser. No. 11/192,886) into the '399 specification is an independent route to treating it as known art.

---

6. Bottom line

On the face of the references printed on US 7,870,399, claims 1–20 present a strong prima facie §103 case. The invention sits at the intersection of four mature technologies — emulated/virtual TPMs (Scarlata '781, Goud '370, Bade '120, IBM '521), the TCG TSS/TPM specifications, automated software fortification (Rice '047, Purdue '686, Atallah), and algebraic data splitting (Orsini '687, Denning & Smid, Blum) — and the applicant's own specification supplies both the motivation ("without requiring the presence of a hardware TPM device") and the confirmatory admissions ("All of the STPM components are compliant with the standards set forth by the [TCG]"; the driver "acts as the root of trust when no hardware TPM is available"). The most defensible non-obviousness positions lie in (i) the three-way guard/TSP/driver binding and (ii) the recitation in claims 18–20 of splitting inside secure data storage registers.

Uncertainties I cannot resolve from the material provided: I have not reviewed the prosecution history of application 11/672,054, so I cannot identify what art the examiner actually applied during pendency (the asterisked examiner-cited references — Scarlata '781, Bade '120, and Beresnevichiene '568 — are the likely candidates, which would make any new §103 challenge turn on references the examiner did not consider, e.g., Goud '370 or Orsini '687). I also have not independently verified the extent to which Orsini '687 or Goud '370 were considered in any sibling or family prosecution.