US 7681050

I'll search for authoritative records on this specific patent number.

Let me check for litigation/docket activity and current USPTO status.

US 7,681,050 B2 — Verified Summary

Source of record: Google Patents full text (fetched 2026-09-28) + Justia/USPTO.report listings. No results were found for any other patent number; all hits below are keyed to 7681050.

---

Bibliographic data

Abstract (verbatim): "A device (e.g., mobile device) and method are described herein that can protect data stored in a rewritable openly accessible memory from replay attacks by using an integrity key and an encryption key to en/decrypt the data, integrity protect the data via a MAC calculation, and verify the data."

---

Plain-language overview of the independent claims

Claim 1 — Method (key generation + confidential storage). Generate one or more keys, MIK_n and, if desired, MCK_n; protect data with them, where the protection includes confidentiality protecting the data by applying an encryption method using MCK_n; store the protected data in the rewritable, openly accessible memory. The generating step must (i) occur inside a tamper-proof module and use a pseudo-random function (PRF), a secret key (PK), and a monotonic-register counter value (n); and (ii) be arranged so that both the current keys (MIK_n / MCK_n) and the next keys (MIK_n+1 / MCK_n+1) can be produced — i.e., the design must allow forward generation.

Claim 2 — Method (the replay-proof update cycle). Six steps: (1) verify integrity of the old data already in the rewritable openly accessible memory using the current keys (MIK_n, optionally MCK_n); (2) calculate new keys MIK_n+1 / MCK_n+1 from PRF(PK, n+1); (3) protect the verified old data and any new data under those new keys; (4) store the newly protected data; (5) increment the monotone register to n+1; and (6) erase the old, previously verified data. Key sequencing point: protection under the new keys and storage happen before the counter is stepped and the old copy erased. Dependents 3–8 add: on failed verification, erase or mark invalid (3); integrity/encryption key definitions (4); MAC-based integrity protection (5); encrypted data (6); encryption-based confidentiality (7); and data being a DRM counter and/or SIM prepaid amount (8).

Claim 9 — Device (apparatus counterpart of claim 2). A device with a tamper-proof module (processor + protected software) and a rewritable openly accessible memory, the module performing exactly the claim-2 sequence: verify old data with current keys → compute new keys via PRF(PK, n+1) → protect verified old + new data with the new keys → store → increment monotone register to n+1 → erase the verified old data. Dependents 10–15 mirror claim 3–7 subject matter and add (claim 15) that the monotone register may be held in physical protected memory, EPROM, EEPROM, or an electronic fuse.

Claim 16 — Device (selective / per-part protection, FIG. 3 embodiment). A device whose tamper-proof module generates key(s) from PRF, PK and monotonic-register counter value n, protects an individual part of data with those key(s), and stores that protected part together with the counter value n it was protected under. The module likewise protects other individual parts with other generated keys and stores each of those with its own corresponding counter value. Practical effect: unchanged data need not be re-encrypted/re-MAC'd on every counter update.

Claim 17 — Device (per-part MAC plus aggregate MAC). Same per-part generation/protection/storage as claim 16, plus: the module integrity-protects each individual part by calculating a MAC for it, and then integrity-protects all of the parts collectively by calculating a MAC over all the stored monotonic-register counter values associated with all the individual parts (the specification labels this "MAC Kn4"). This is the anti-swapping measure — it detects an attacker re-associating one protected part with another's counter.

---

Prior art cited (21 references)

Notably US 5,757,919 (Intel, cryptographically protected paging subsystem); WO 2001/033317 A1 (Philips, assuring data integrity via a secure counter); US 6,836,853 B1 (Intel, non-volatile memory based monotonic counter); US 2004/0003244 A1 (England, multiplexing a secure counter to implement second level secure counters); WO 03/081549 A2 (Ericsson, secure handling of stored-value data objects). Non-patent literature includes Lamport, "Password Authentication with Insecure Communication," Comm. ACM Nov. 1981, and Schneier, Applied Cryptography, 2nd ed.

---

Litigation / docket check — explicit uncertainty

I searched for a CAFC 2026 docket, PTAB proceeding (IPR/PGR), or district-court action naming 7,681,050 specifically, and found no authoritative record. Two caveats:

1. My searches were general web queries, not a direct query of the CAFC docket system or USPTO PatentCenter/PTAB APIs, so absence of results is not proof there is no 2026 proceeding. A FOIA-quality check would require PACER/CAFC CM-ECF and USPTO PTAB docket lookups.
2. The only current-status signal I have is Google Patents' "Active / expires 2029-01-13" and the fee-payment record through the 12-year fee (2021). No lapse, adverse judgment, or disclaimer appears in the retrieved record.

---

Two text-integrity flags (interpreted literally, not corrected)

• "PRE" for "PRF." The claim text as rendered on the retrieved pages spells the function "pseudo random function (PRE)" in claims 1, 9 and 17, while the specification and other claims use "PRF." This is almost certainly an OCR artifact, but I am reporting the strings as they appear rather than silently normalizing them.
• Claim 1 differs between documents. The granted US 7,681,050 claim set (authoritative, per supplied full text) folds the "confidentiality protecting the data by applying an encryption method … using the MCK_n" limitation into claim 1, and claim 2 is a separate independent method claim. The earlier pre-grant publication US 2007/0130470 A1 (as reproduced on Justia) instead shows a claim 1 without that encryption limitation, a dependent claim 2 on keys, and a claim 7 that is the counterpart of granted claim 2. Anyone relying on claim scope should cite the granted text, not the pre-grant publication.

I'll research litigation involving US patent 7681050 by searching litigation databases and other sources.

Let me search more specific litigation databases.

Let me check specific litigation tracking sites and dockets.

Litigation Search Results: US Patent 7,681,050

I found no litigation specifically asserting or involving US Patent 7,681,050 ("Secure and replay protected memory storage," Telefonaktiebolaget LM Ericsson AB, filed 2005-12-01, granted 2010-03-16).

What I searched

I ran searches across general web results and litigation-related sources (Unified Patents litigation caselist, PACER/CourtListener references, Justia/patent-litigation aggregators) using the literal identifiers 7681050, 7,681,050, and US7681050B2, cross-referenced with the patent title and assignee (Ericsson).

What the searches returned

Important cautions — do NOT conflate these with the '050 patent

The searches surfaced several cases that involve different patent numbers, and I am flagging them so they are not mistakenly attributed to US 7,681,050:

1. LifeScan, Inc. v. Shasta Technologies, LLC, et al. (N.D. Cal., Case Nos. CV11-04494 and 12-cv-6360) — this litigation concerns U.S. Patent No. 7,250,105 (the "'105 patent"), together with U.S. Patent Nos. 5,708,247 and 6,241,862. 7,250,105 is not 7,681,050; these are different patents owned by different entities (LifeScan, not Ericsson). Do not attribute this case to the '050 patent.

2. Ericsson v. ASUSTeK Computer Inc. / Arvato Netherlands B.V. (UPC, Milan Local Division, and UPC Court of Appeal). This is Ericsson SEP/FRAND litigation, but the patents at issue are EP 2 727 342, EP 3 076 673, and (in the Lisbon decision) EP 2819131 B1 — not EP 1958114 B1, which is the European family member of the '050 patent. So even this Ericsson case does not concern the '050 patent.

3. ASUS Technology Licensing Inc. v. AT&T Inc., et al. (e.g., 2:23-cv-00486) — a separate FRAND/SEP matter; no indication it involves the '050 patent.

Family / status notes for the '050 patent itself (for context, not litigation)

• US 7,681,050 B2 — active; adjusted expiration listed as 2029-01-13; maintenance fees paid through the 12th year.
• Family members: US20070130470A1 (pub.), WO2007062941A2, EP1958114B1 (granted, then lapsed/ceased), JP2009517939A, TWI407745B, TW200805978A. None of these showed enforcement activity in the search results.

Conclusion

Based on the searches performed, there is no known litigation involving US Patent 7,681,050. I could not identify any plaintiff, defendant, jurisdiction, case number, or filing date for a case asserting or challenging this specific patent.

Caveats and verification recommended:

• My searches were limited and may not be exhaustive. Absence of results is not proof of absence of litigation.
• Because this patent appears to date from 2005–2010 and its EP counterpart (EP1958114B1) is now lapsed, it is plausible that this patent was licensed rather than litigated (Ericsson is a large licensor), but I cannot confirm this — I have no source stating either way.
• For a definitive answer I would recommend directly querying PACER/RECAP (CourtListener), Docket Alarm, Unified Patents' litigation portal (the caselist URL you cited), and Lex Machina / Darts-IP, searching the exact string 7,681,050. I was unable to complete those targeted docket-level queries within the tool limits of this session.

If you'd like, I can attempt those docket-specific lookups directly (e.g., a CourtListener RECAP search for "7,681,050") and report exact case numbers if any exist.

I'll verify the structured block's "no proceedings" signal against public sources before writing this up.

The initial results are dominated by other "768" patents (7,251,768; 8,085,768; etc.). Let me run patent-number-specific queries.

The number-specific queries return only unrelated patents that happen to share a "768" or "7681" fragment. Let me run a couple of final due-diligence searches.

PTAB Proceedings — US 7,681,050 ("Secure and replay protected memory storage")

Proceedings overview

Total AIA trial proceedings on file: 0. The structured ODP block reports no AIA trial proceedings, and independent web searching surfaced no IPR, PGR, or CBM involving US 7,681,050 — no institution decisions, no Final Written Decisions, no settlement terminations, and no Federal Circuit appeals. This patent has never been institution-tested at the Board, so there is no claim-level validity ruling to hand a defendant; "the patent has survived" is simply not an accurate framing, because it was never attacked at the PTAB in the first place.

---

No proceedings to report

Because the count is zero, there is no per-proceeding breakdown by status (active / claims invalidated / claims sustained / settled / institution denied). For completeness, the record of this patent's post-grant life shows:

• 2010-03-16 — Patent granted (US 7,681,050 B2; filed 2005-12-01; inventors Rolf Blom and Christian Gehrmann; assignee Telefonaktiebolaget LM Ericsson).
• 2010-11-09 — Certificate of Correction issued. This is a routine correction document, not a reexamination or a post-grant review.
• Maintenance fees — Paid at 4-, 8-, and 12-year intervals (most recently 2021-09-16), so the patent remains in force with an adjusted expiration of 2029-01-13 per the Google Patents record.
• No IPR/PGR/CBM number, no Board panel, no institution decision, no FWD, no settlement, and no CAFC appeal exists for this patent in any source I could reach.

Important false-positive warning. Searches for the shorthand "the '768 patent" return a different, unrelated patent — a 2019-issued patent in a large III-V/semiconductor or multi-node family that has been the subject of IPR2025-00794 (Intel), related IPRs against its parent patents, and litigation in D. Minn. and Texas. Those matters involve Cornell/MultiMATLAB prior art and Regents of the University of Minnesota–style subject matter and do not concern US 7,681,050. Similarly, Ericsson Inc. v. Regents of the University of Minnesota, IPR2017-01197 (U.S. Patent 7,251,768) is an Ericsson-family IPR against a different patent number. Do not let a "768"-string search mislead you into citing these as proceedings on the patent at issue.

---

Strategic summary

Claim status. Because no AIA trial has ever reached a Final Written Decision, every claim of US 7,681,050 is UNTESTED at the PTAB. That means claims 1–17 are neither canceled, nor confirmed, nor amended by the Board. There is no narrowing through IPR, no surviving-claim list to point to, and no Board claim construction to rely on. A defendant cannot truthfully say any claim of this patent "is dead" as a result of PTAB action — no such action exists.

Estoppel landscape. With no petitioner, there is no § 315(e)(2) estoppel attaching to anyone. A defendant is free to raise any prior-art ground in district court or in a fresh IPR petition, including art that might otherwise have been estopped had a prior petitioner already run a trial. The only cloud on the horizon is the patent's age and the current institution environment: the patent's 2005 priority date and 2010 grant mean broad pre-AIA art is available, but the USPTO's 2024–2026 tightening of discretionary institution (the emerging "settled expectations" line of denials, discussed in Unified Patents amicus briefing in No. 25-1230) makes institution on a long-issued patent less routine than it once was. Note, however, that the 2029 adjusted expiration means the patent is still within its enforceability window, so recent assertions are not barred by age.

Pattern signals. None. No serial petitioner, no defensive aggregator (Unified Patents, RPX, etc.) in the chain, and no history of the patent owner pursuing PTAB appeals — because there has been no PTAB activity to appeal. Patent owner Ericsson is an operating company (not an NPE), which historically correlates with lower IPR-challenge volume on its own portfolio, but that is a general observation, not evidence about this patent.

---

Recommended next steps

• If you are a defendant and the patent owner cites PTAB history: correct the record. There is none. Ask for the proceeding number; there is no IPR/PGR/CBM to produce. Verify independently at USPTO PTAB E2E / PTAB Decisions and Google Patents for US7681050B2.
• If you are weighing an IPR: treat this as a clean-slate petition. No estoppel, no prior Board constructions, and no earlier FWD to differentiate. The patent's pre-AIA priority (2005-12-01) opens up a wide art window, and the claims are structurally narrow (key generation via PRF over a secret device key and a monotonic counter, with MAC/encryption protection of rewritable memory). The absence of any prior challenge means the strongest art has likely never been run against it.
• If you are waiting on active proceedings: there are none to track. No institution deadlines, no oral-hearing dates, and no statutory 1-year FWD clock are running for this patent.
• Timing note: the patent carries an adjusted expiration of 2029-01-13, so an IPR would still have several years of runway to meaningfully blunt an assertion campaign.

Bottom line: The absence of PTAB activity is itself the signal. This is a live, in-force Ericsson patent that, as of the most recent data available to me, has never been challenged at the Board. Any defense strategy must be built from the ground up rather than from a prior FWD — and any assertion of "the patent was already invalidated" against you would be factually wrong.

Methodology / confidence note: this conclusion rests on the ODP "no proceedings" block plus web search that produced only unrelated "768"-fragment matches. I could not exhaustively query paid dockets (Docket Navigator) or the full PTAB E2E document set within this session, so treat "zero proceedings" as high-confidence but not court-certified. If a demand letter implies otherwise, demand the proceeding number.

I'll verify the assignment record against the live sources before reconstructing the chain.

Let me cross-check the assignment record against Espacenet INPADOC, which mirrors the same USPTO assignment data.

Assignment Record Reconstruction — US 7,681,050 B2

Patent: US 7,681,050 B2 — "Secure and replay protected memory storage" (17 claims)
App. No.: 11/275,015 | Filed: 2005-12-01 (no earlier priority claim; the 2005-12-01 date is both filing and priority date) | Issued: 2010-03-16 | Adjusted expiration: 2029-01-13 | Status: Active

Sourcing note / limitation. The USPTO Assignment Center (assignmentcenter.uspto.gov) and the legacy assignment.uspto.gov index are JavaScript applications that I cannot render directly, so I cross-verified the chain against two independent USPTO-derived mirrors that surface the same underlying assignment records: the Google Patents "Legal Events" table for US7681050B2 and PlainSite's USPTO assignment index (which returns the recording against application 11/275,015 / publication 20070130470 / patent 7681050). Both return exactly one assignment entry. I found no evidence of any second recording, and I am reporting that absence as a finding rather than filling the gap with inference.

---

Inventors

Pattern check — "all inventors gone within 12 months"? Not present. This is the opposite of the fire-sale precursor pattern:

• The assignment was executed by the inventors individually in favor of Ericsson, with signing dates spanning 2005-11-30 to 2005-12-19 (Google Patents legal-event free text: ASSIGNORS:BLOM, ROLF; GEHRMANN, CHRISTIAN; SIGNING DATES FROM 20051130 TO 20051219). Two signatures straddling the 2005-12-01 filing date is the ordinary employee-invention confirmatory pair, not a departing-inventor signature.
• Gehrmann continued to assign security-related inventions to Ericsson for roughly another decade — the PlainSite index shows Ericsson assignments by him recorded as late as 2016-04-27 (e.g. app. 14/902,316). He later appears as a professor at Lund University and by 2018–2020 was assigning biometric-security applications to Fingerprint Cards AB. That is a career move, not a portfolio unwind, and it occurred ~13 years post-filing. US 7,681,050 is not among the patents that moved to Fingerprint Cards — it stayed with Ericsson.
• No evidence found that Blom departed Ericsson within 12 months of filing.

Caveat: the date ordering above is Blom-then-Gehrmann as recorded; I cannot confirm from the indexed data which inventor signed on which of the two dates.

---

Original assignee

Telefonaktiebolaget LM Ericsson (publ), S-164 83 Stockholm, Sweden. Original assignee and — per the records below — still the owner of record.

• Line of business: global telecom network infrastructure (radio access, core network, transport) plus, at the relevant time, the Ericsson Mobile Platforms handset-chipset business — i.e. baseband platforms with embedded security. That business unit is the most plausible commercial embodiment of a "tamper-proof module … on a baseband chip" as described in the specification (the disclosure explicitly places the tamper-proof module and the monotone-register storage on a baseband chip in the mobile-phone case).
• Did they ship a product embodying the claims? Grounded inference, not documented evidence: Ericsson's platforms business shipped secure-boot / protected-memory baseband silicon in this era, and the facing-page file history shows the same inventors on Ericsson's sibling secure-memory patents (US 8,036,380; US 8,627,086; US 8,215,550). I have not located a product datasheet or claim-chart establishing that a specific shipping Ericsson product reads on these claims — treat the product question as unproven.
• Status: Operating, publicly listed (NASDAQ: ERIC; Nasdaq Stockholm: ERIC-B). Not acquired, not dissolved, not in bankruptcy. Maintenance fees confirm this — see below.
• Naming note: Google Patents normalizes the current assignee to "Telefonaktiebolaget LM Ericsson AB"; the recorded assignee is "TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)". These are the same legal entity (AB = aktiebolag; "(publ)" = public limited). No change-of-name document is recorded against this patent. (Related Ericsson US patents do carry change-of-name housekeeping filings — e.g. reel 040193/0836, changing "TELEFONAKTIEBOLAGET L M ERICSSON (PUBL)" to the no-space form — but US 7,681,050's recorded assignee name already matched the current form, so none was needed.)

---

Assignment timeline

1. Inventor → Ericsson (the only recorded assignment)

• 2005-11-30 / 2005-12-19 (executed, per-inventor) / recorded 2006-08-08 — Reel 018072/0770
  • Conveyance: Assignment (Assignment of Interest — ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS))
  • Assignor: Blom, Rolf; Gehrmann, Christian (individually)
  • Assignee: Telefonaktiebolaget LM Ericsson (publ), Sweden
  • Correspondent: Not exposed in the indexed record. The Google Patents legal-event entry for reel 018072/0770 does not list a correspondent/attorney of record, and I could not retrieve the face of the recorded instrument. Circumstantial data point only: sibling Ericsson security patents of the same vintage name ERICSSON INC., PLANO, TX as the attorney/agent firm (e.g. US 8,627,086, app. 11/577,084), i.e. Ericsson's in-house IP operation recorded its own assignments. I am not asserting the correspondent for this reel — it is unverified. No recurrence check is possible on a chain of length one.
  • Context: Ordinary employee-invention assignment to the employer — the inventors personally conveyed to Ericsson, not an intra-corporate reorg and not a sale.

Post-issuance record

There are no post-issuance assignments of any kind. No merger, no change of name, no security agreement, no license, no release, no correction of assignment name, and no transfer to any third party. The remainder of the Google Patents legal-events table consists entirely of PTO-side administrative events:

• 2010-02-24 — patent grant; 2010-03-16 — US7681050B2 published
• 2010-11-09 — Certificate of Correction (a PTO instrument, not an assignment)
• 2013-03-18 — 4th-year maintenance fee paid
• 2017-09-18 — 8th-year maintenance fee paid
• 2021-09-16 — 12th-year maintenance fee paid, recorded as 12TH YEAR, LARGE ENTITY (M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

That last entry is an affirmative, documentary data point: as of 2021-09-16 the owner of record claimed large-entity status when paying the 12th-year fee. A single-purpose small/micro-entity NPE shell would normally claim small- or micro-entity status. Nothing in the record is consistent with an NPE holding.

Family members for completeness (same priority, different jurisdictions, no US ownership effect): WO2007062941A2 (PCT/EP2006/067807, filed 2006-10-26, now Ceased), EP1958114B1 (granted 2017-12-06), JP2009517939A, TWI407745B (IP right cessation).

---

Timeline diagram

timeline
    title Ownership of US 7681050
    2005 : Invention filed on 2005-12-01
         : Inventors sign assignment Nov-Dec
    2006 : Assignment recorded Aug 8 to Ericsson
    2010 : Patent issued Mar 16
         : Certificate of Correction issued
    2013 : Fourth year maintenance fee paid
    2017 : Eighth year maintenance fee paid
    2021 : Twelfth year fee paid as large entity

---

NPE / troll-pattern signals

Inverse signal worth noting: the plainest reading of the record is that this patent was never commercialized as an assertion asset in the secondary market — it was maintained by Ericsson in-house at large-entity rates for its full term.

---

Verdict

Insufficient data (only the original assignment).

The entire ownership history consists of a single instrument: the inventors' assignment to Telefonaktiebolaget LM Ericsson (publ), executed 2005-11-30/2005-12-19 and recorded 2006-08-08 at reel 018072/0770. Every downstream signal that would indicate an NPE chain — shell transfer, cascading LLC hops, repeat correspondent, pre-litigation transfer, fire-sale — is absent by construction, because no second assignment exists; the 2013, 2017 and 2021 maintenance-fee payments recorded as LARGE ENTITY (entity status of patent owner: large entity) confirm Ericsson held the patent continuously and treated itself as a large operating entity. The absence of any post-issuance assignment is not a data gap I am papering over — it is the finding: this is an operating-company-held patent with no secondary-market or NPE history.

Two residual uncertainties I flag rather than resolve: (a) the correspondent of record for reel 018072/0770 is not exposed in the indexed sources, so I could not run the repeat-correspondent check; and (b) I could not render the Assignment Center UI directly, relying instead on two USPTO-derived mirrors that agree with each other.

Verify at: USPTO Assignment Center — search patent number 7681050 (or app. 11/275,015); legacy equivalent: assignment.uspto.gov/patent. Legal-events mirror: patents.google.com/patent/US7681050B2/en.

I'll verify the patent record and pull details on the cited references.

Let me pull details on the most technically relevant cited references.

Scope and method

I ran searches keyed to the exact string 7681050 against the Google Patents full-text record (which mirrors the USPTO front page), the Justia grant page, and the uspto.report grant page. No results surfaced for any other patent number, and the bibliographic data returned matched the record already established for US 7,681,050 B2 ("Secure and replay protected memory storage"). I did not run a direct PatentCenter/PTAB API query, so this is a metadata-level confirmation, not a certified-status check.

One threshold point that governs everything below: this application was filed 2005-12-01, so pre-AIA 35 U.S.C. §§ 102/103 apply (the AIA first-inventor-to-file §§ 102/103 govern applications filed on or after 2013-03-16). That matters because several cited references were published after the 2005 priority date but were filed before it, making them §102(e) art only; and one group (the "Family Cites Families" list) is prosecution-level art that surfaced in the EP counterpart, not necessarily before the US examiner.

I cannot state from the retrieved record which references the examiner actually applied in a §102 rejection versus a §103 combination — that requires the file wrapper. So below I give the claim-overlap assessment and, where relevant, flag that the reference is more naturally §103 combination art than §102 anticipatory art. A single reference anticipates under §102 only if it discloses every limitation of the claim; on this record, no cited reference appears to disclose the full combination of independent claims 1, 2, 9, 16 or 17.

---

The cited references, ranked by relevance to the claims

Tier 1 — direct on-point subject matter

1. US 5,757,919 A — "Cryptographically protected paging subsystem" (Intel Corp.; Herbert & Davis)

• Filed/priority: 1996-12-12 · Published/granted: 1998-05-26 (family: WO 98/26535, GB 2 334 866, DE 19782169, US 6,708,274 B2 continuation)
• Description: A physically secure environment exports pages to insecure external storage. An outgoing page is integrity-tagged (one-way hash → integrity check value, "ICV") and then encrypted (IDEA/DES) before export; on paging back in, the page is decrypted, re-hashed, and the recalculated ICV compared to the stored ICV; mismatch → page discarded with a "data corrupt" signal.
• Claim overlap: This is the reference most structurally analogous to the confidentiality-plus-integrity protection of data held in openly accessible memory, i.e., the FIG. 1 architecture and the "encryption method 114 + MAC method 116" pairing in claims 1, 9 and dependents 5–7, 12–14.
• §102 potential: Weak for §102. It stores an ICV rather than deriving keys from PRF(PK, n), has no monotone register, no key rotation, and no verify→re-protect→increment→erase ordering. Expect it as §103 art combined with a monotonic-counter/counter-bound-key reference (see items 5, 8, 9, 12).

2. WO 01/033317 A1 — "Assuring data integrity via a secure counter" (Koninklijke Philips Electronics N.V.)

• Priority: 1999-10-29 · Published: 2001-05-10
• Description: A secure module holds a usage parameter in a counter 111; the usage parameter is bound to the protected database by computing a hash 131 over the data plus the usage parameter. On access, the stored binding value is compared against the binding of the current counter value with the data; any mismatch (data changed or counter rolled back) denies access. Explicitly frames the problem as defeating replay attacks on stored-value/financial records.
• Claim overlap: Closest to the verify-old-data-before-proceeding step of claims 2 and 9, and conceptually to the counter-bound-to-data idea underlying claims 16/17. Also relevant to claim 8 (stored-value/prepaid-amount subject matter).
• §102 potential: Weak-to-moderate for §102. It teaches counter-bound integrity and replay detection, but not derivation of encryption/integrity keys as PRF(PK, n) inside a tamper-proof module, and not the two-key (MCK/MIK) split. Likely §103 art.

3. US 2004/0003244 A1 — "Multiplexing a secure counter to implement second level secure counters" (Paul England; [Microsoft Corp.](/litigations/by-plaintiff/Microsoft%20Corp.); granted as US 7,421,579 B2; EP 1 376 306 A2/A3)

• Priority/filed: 2002-06-28 · Published: 2004-01-01
• Description: A parent (first-level) secure counter backs a multiplicity of child counters. Each child counter value is stored together with the parent counter value and a signature in a file that need not itself be secure. To read: verify signature and compare the stored parent value to the current parent value. To increment: same checks, then increment the child and the parent, then re-sign. Rollback is detected because a substituted older file carries a stale parent value that no longer matches.
• Claim overlap: This is the closest cited art to claim 16 — storing "the protected individual part of data and the monotonic register counter value (n)" together, and doing so for multiple parts each with its own counter value. It also bears on the verify-before-increment sequencing of claims 2/9 and anticipates the anti-swap concern addressed by claim 17.
• §102 potential: Strongest §102 candidate among the 21, and specifically for claim 16 — but only if one maps "signature by a trusted entity" onto the claim's PRF(PK, n)-generated key, which is a stretch: the claims require the key derived from the counter value, not a signature covering the counter value. Expect §103.

4. US 6,836,853 B1 — "Non-volatile memory based monotonic counter" (Intel Corp.; Dover & Gafken)

• Priority/filed: 1999-12-31 · Granted: 2004-12-28
• Description: A monotonic count is maintained as a volatile counter (low-order bits) plus a non-volatile-memory-based counter (high-order bits), with control logic governing updates (e.g., update on read, update on power-on-reset, flash bit programming). Related Intel family: US 6,687,325 / US 7,085,341 ("Counter with non-uniform digit base").
• Claim overlap: Directly on the realization of the monotone register (MR) 112 recited in claims 2, 9, and expressly on claim 15 ("physical protected memory, an EPROM, an EEPROM or an electronic fuse").
• §102 potential: Not anticipatory of any independent claim alone (no data protection, no keys). §103 art for the counter-implementation aspect, especially against claims 2/9/15.

5. US 2004/0126093 A1 — "Conditional access system and method prevention of replay attacks" (Platt, David C.)

• Priority: 2001-03-02 · Published: 2004-07-01
• Claim overlap: Title-level subject matter is squarely the replay-attack prevention purpose stated in the abstract and claims 2/9.
• §102 potential: I do not have the substantive text of this reference in the retrieved record, so I will not characterize its disclosures. Treat the description above as derived from bibliographic data only.

6. WO 03/081549 A2 — "Secure handling of stored-value data objects" (Ericsson Inc.)

• Priority: 2002-03-21 · Published: 2003-10-02
• Claim overlap: Same assignee's earlier work on stored-value data objects, i.e., the SIM-prepaid-amount and DRM-counter subject matter of claim 8 and the background section's SIM example.
• §102 potential: Not verified in this session (search budget exhausted before retrieval); treat as bibliographic-only unless the file wrapper confirms it was applied. Note it is the applicant's own prior art, which makes it relevant to the §102(a)/(b) analysis if it published before 2005-12-01 — it did (2003).

7. US 6,832,317 B1 — "Personal computer security mechanism" (Advanced Micro Devices, Inc.)

• Priority: 2001-05-10 · Granted: 2004-12-14
• Claim overlap: General trusted-platform/hardware security art bearing on the "tamper-proof module" recitation in claims 1, 9, 16, 17.
• §102 potential: Bibliographic-only characterization; broad-platform §103 art at most.

8. WO 2005/008385 A2 — "Reprogrammable security for controlling piracy and enabling interactive content" (Cryptography Research, Inc.)

• Priority: 2003-07-07 · Published: 2005-01-27
• Claim overlap: Content-protection/rekeying art bearing on claims 1/9 (key generation) and claim 8 (DRM).
• §102 potential: Bibliographic-only characterization; §103 at most.

---

Tier 2 — supporting/background art (bibliographic-only characterization)

For these I have title, assignee and dates from the authoritative citation table but not substantive text, so I am deliberately not asserting what they disclose.

Timing note for items 15–21: all have priority dates before 2005-12-01, so they can only be §102(e) art (published after the filing date but filed before it) — they cannot be §102(a)/(b) art. Items 9–14 all published before the 2005-12-01 filing date and thus qualify as §102(b) art. Item 8 (WO 2005/008385, published 2005-01-27) likewise qualifies as §102(b) art; note, however, that it published within one year of the filing date, so it is also within the §102(b) grace-period calculus if the inventors' own work is implicated.

---

Family-level citations (EP prosecution), separately

The record lists 10 "Family Cites Families" references that surfaced in the EP 1 958 114 counterpart, not necessarily before the US examiner. The most consequential is:

• US 7,043,636 B2 — "Data integrity mechanisms for static and dynamic data" (Telefonaktiebolaget LM Ericsson (publ), 2006-05-09; priority 2000-09-26). Same assignee, and its title maps onto the static/dynamic-data integrity problem the instant patent addresses — worth flagging as the family reference most likely to have been cited substantively.
• Also listed: JPH07191836A (Canon), US 7,194,092 B1 (Microsoft, "Key-based secure storage"), JP3644320B2 (NEC), US 2002/0191783 A1 and US 7,249,255 B2 (hash/digest apparatus), TWI224455B (Mitake Data), JP2003032244A (NEC, stream cipher), TW595183B (Acer Labs, crypto circuit), US 7,624,272 B2 (Intel, platform information for digital signatures).

---

Non-patent literature cited

• Lamport, L., "Password Authentication with Insecure Communication," Communications of the ACM, Nov. 1981, vol. 24, No. 11, pp. 770–772. The canonical one-time-authenticator/chained-value reference; relevant to the "old keys cannot be regenerated / old data recognizable as obsolete" principle in the specification.
• Schneier, B., Applied Cryptography, 2nd ed., John Wiley & Sons, 1999, pp. 28–29, 169–175, 189–197, 357–363. The standard MAC/HMAC and key-derivation background; supports the HMAC-with-SHA-1 implementation recited in the specification for MAC method 116.
• Anciaux, N., "Data Confidentiality: to Which Extent Cryptography and Secured Hardware Can Help." Hardware-assisted confidentiality background.

---

Bottom line for a §102 attack

• No single one of the 21 cited references discloses every limitation of any of independent claims 1, 2, 9, 16 or 17. The claims require a specific combination: key derivation as PRF(PK, counter) inside a tamper-proof module, the two-key (MIK/MCK) confidentiality-plus-integrity pairing, and the verify-old → protect-old-and-new-under-next-keys → store → increment-MR → erase-old ordering, with the counter update deliberately deferred until after re-protection.
• The three references a challenger would build a §102 argument around are US 5,757,919 (encrypt + integrity-tag data in insecure storage), WO 01/033317 (secure counter bound to data to defeat replay), and US 7,421,579 / US 2004/0003244 (per-part storage of a protected value with its counter value, verified against the current counter before use). The last of these is the only one that maps onto claim 16's "store the protected individual part of data and the monotonic register counter value (n) together."
• Everything else is best characterized as §103 combination art (item 4 for the monotone-register realization of claims 2/9/15; item 19 for the backup/restore/replay purpose; items 15–21 as §102(e)-only art).

Caveats I want on the record: (i) I could not retrieve substantive text for items 5–21 within this session, so those entries are bibliographic-only and I have not asserted their disclosures; (ii) I have not confirmed the examiner's actual rejection grounds from the file wrapper, so the §102-vs-§103 allocation above is my technical assessment, not a record of prosecution; and (iii) WO 03/081549 A2 is the assignee's own prior stored-value work and warrants a direct read if a §102(b) attack is contemplated.

I'll ground the key prior-art references before building the § 103 analysis.

Let me pull details on the remaining key references, including the Ericsson family citation and the Philips secure-counter disclosure.

Obviousness Analysis — US 7,681,050 B2 under 35 U.S.C. § 103

Patent: US 7,681,050 B2 ("Secure and replay protected memory storage"), US App. 11/275,015, filed & priority 2005-12-01, granted 2010-03-16, assignee Telefonaktiebolaget LM Ericsson (publ).
Source of record: https://patents.google.com/patent/[US7681050B2](/patent/US7681050B2)/en (full text + "Patent Citations (21)", "Non-Patent Citations (5)", "Family Cites Families (10)").
Task: identify prior-art combinations that would render the claims obvious and explain the motivation to combine.

Standing caveats. (1) This is an analyst's § 103 assessment, not a legal opinion or a validity conclusion; a real challenge needs claim charts against full reference texts plus the file history, which is not in the provided record. (2) I retrieved abstracts/claims for several references but not full texts for WO 2001/033317 A1 (Philips), US 2003/0007437 A1 (Staring), or GB 2351819 A (Sony). Where I rely on title/assignee/abstract rather than full text, I say so explicitly. (3) This builds on the previously generated summary and litigation sections; I flag one addition (not a contradiction) to those sections in § 10.

---

1. Date discipline and governing law

Because the application was filed 2005-12-01, pre-AIA § 103 governs (the AIA's amended § 103 applies only to applications filed on/after 2013-03-16). Pre-AIA § 103 is analyzed under Graham v. John Deere Co., 383 U.S. 1 (1966), with the "expansive and flexible" approach to motivation confirmed in KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), and MPEP § 2143's enumerated rationales.

Critical date for prior art: 2005-12-01. This matters because several references on the face of the patent were published after the critical date and are therefore available only as pre-AIA § 102(e) art (i.e., as of their earlier US filing dates), not as § 102(a)/(b) printed publications:

All the pre-2006 references (Intel, Philips, Sony, Hitachi, HP, AMD, Ericsson, Platt, England, Staring, Cryptography Research, Freeman) predate 2005-12-01 by publication and are squarely available. Any combination I propose below uses only those.

---

2. Element decomposition (what a challenger must supply)

From the previously generated claim summary, the independent claims reduce to five technical kernels:

• K1 — Counter-derived keys: derive MIK_n (and optionally MCK_n) inside a tamper-proof module from PRF(PK, n), where n is a monotonic-register counter value. (Claims 1, 2 step 2, 4, 9, 11, 16, 17.)
• K2 — Confidentiality + integrity protection of data held in rewritable, openly accessible memory. (Claims 1, 5, 6, 7, 9, 12–14.)
• K3 — Verify-before-overwrite ordering: verify old data under the current keys, re-protect the verified old data plus any new data under the next keys, store, then increment the monotone register, then erase the old copy. (Claim 2 steps 1–6; claim 9.)
• K4 — Per-part protection carrying its own counter value: protect an individual data part under key(s) derived from counter n and store it together with n; other parts with other keys/other counters. (Claim 16.)
• K5 — Two-level MAC: a MAC per part, plus a MAC over all the stored counter values associated with all parts. (Claim 17.)

K1 and K3 are the heart of the patent; K4/K5 (the FIG. 3 embodiment) are the narrower, more easily attacked claims.

---

3. The relevant prior art on the record

The record's non-patent citations are themselves telling: the applicants cited Lamport and Schneier — i.e., the patent's own information-disclosure statement concedes that counter-chained keyed functions and MAC-based integrity are textbook.

---

4. Ground 1 — Primary combination: Philips WO 2001/033317 A1 + Intel US 5,757,919 + Intel US 6,836,853 B1 (optionally also Schneier/Lamport) → claims 1, 2, 5–7, 9, 12–15

Where each limitation is found.

• Rewritable openly accessible memory holding confidentiality- and integrity-protected data, with the crypto done in a physically secure/tamper-proof environment — '919, wholesale. '919's secure environment is built from "tamper-resistant packaging materials, tamper-resistant die coatings, and tamper-resistant wafer coatings"; the processor and its ROM code live inside it; the encrypted and ICV'd pages live in the external, attacker-accessible storage. That is '050's FIG. 1 architecture (elements 100, 102, 104, 108).
• Encrypt-then-MAC over data destined for that memory — '919 (encryption engine + integrity check engine; IDEA/DES; one-way hash ICV). This covers claim 6 and, with HMAC per Schneier, claim 5.
• Key derived from a secret and a monotone counter — Philips WO 2001/033317 (integrity protection value computed as a MAC "from a value of said version counter and a secret key value," secret key device-specific, module "secured against modification") plus Intel '853 (the monotone counter itself, including a flash-based realization). Alternatively or additionally, Schneier's teaching of subkey derivation from a master key and a counter makes this a routine step.
• Verify the current value before generating the next one — Philips (subsequent integrity-protection value generated "conditioned on a successful verification of said current counter value") and '919 (incoming page decrypted and ICV-checked before re-export).
• Re-protect all data under a new key, write it back, then obsolete the old copy — '919's cryptoperiod update: page in → decrypt → integrity-check → re-encrypt with a new key/IV → export to external storage; the specification notes it is "unnecessary for the page frames to populate the secure RAM during this update." '853 supplies the complementary teaching that the count is stepped only under the counter's control logic and that read access is disabled during the update window — which is exactly '050's increment-then-erase and step-216 "lock."
• Separate confidentiality key (MCK) and integrity key (MIK) — claims 4/11: routine key separation (Schneier), and structurally present in '919, which uses a distinct encryption key/IV and a distinct hash/ICV path.
• Monotone register realized in protected flash / EPROM / EEPROM / electronic fuse — claim 15: '853 claims exactly that (flash programming bit locations; volatile+non-volatile pairing; power-on-reset update).
• Erase or mark invalid on failed verification (claims 3/10) — '919 ("the page is discarded… and a data corrupt message is sent") and England. '050's own text says only that the failed data "is erased or marked as invalid" — a binary choice squarely anticipated by '919's discard behavior read with England's read-failure handling.

Why a POSITA would have combined them (MPEP § 2143 rationales).

1. Same field, same problem, same solution class. All three references address the storage of security-critical state in memory an adversary can read and rewrite. Philips' own title is "Assuring data integrity via a secure counter"; '853's stated purpose is to "help prevent the reoccurrence of a prior count"; '919's stated purpose is maintaining "integrity and confidentiality of pages paged to an external storage unit from a physically secure environment." Combination is not cross-industry borrowing.
2. Combining prior-art elements according to known methods, yielding predictable results (MPEP 2143(A)). Putting a monotone counter (Intel '853) next to a counter-keyed MAC (Philips) and a split secure/insecure memory with encryption + ICV ('919) is the assembly of three known, compatible security primitives. Each retains exactly its known function: the counter supplies freshness, the PRF/EVP supplies key derivation, the encryption and MAC supply confidentiality and integrity. There is no unpredictable interaction.
3. Simple substitution (MPEP 2143(B)). '919 already re-keys pages, generating "a new key and IV (either or both of which may be generated on an application or page by page basis)" at each cryptoperiod. Substituting counter-derived keys for randomly generated keys is a substitution of one known keying scheme for another, and it buys a known benefit: the key can be redetermined from the device's own monotone state rather than stored, which is precisely what an artisan building a device with limited protected storage would want.
4. Known technique improving a similar device in the same way (MPEP 2143(C)). The counter-ladder technique (Lamport 1981) was standard for making old values non-regenerable; applying it to '919's re-key cycle predictably yields forward-only key evolution.
5. Design incentives / market forces (MPEP 2143(F)). The '050 specification itself concedes the motivating art: SIM prepaid-balance replay (which it calls "well known from the early times of telephone cards") and DRM play-counters. The record's Ericsson stored-value reference (WO 03/081549 A2) and Platt's conditional-access replay reference supply independent, pre-2005 recognition of the same market need. Meanwhile the economics of handset memory push the security state out of the expensive tamper-proof die and into cheap rewritable flash — the very architecture '919 taught and '050 adopts.
6. Reasonable expectation of success. Every step is deterministic: PRF outputs are reproducible, MACs are verifiable, and counter advancement is a hardware-controlled operation ('853). Nothing here requires experimentation or the discovery of an unknowable property; at most it is "obvious to try" a finite, identified set of key-derivation options with predictable results (KSR, 550 U.S. at 421).

Result. Claims 1, 2, 5, 6, 7, 9, 12, 13, 14 and 15 would be prima facie obvious over Philips + '919 + '853, with Schneier/Lamport supplying the conventionality of PRF-based key derivation, HMAC, and key separation; claims 3 and 10 over the same combination in view of '919's discard-on-mismatch.

Weak link a challenger must shore up: the specific ordering in claim 2 (protect-and-store → then increment → then erase). '919 teaches re-protection and re-export but does not use a monotone counter as the ordering pivot; '853 teaches counter-update control but not the re-protection cycle. The bridge is that a POSITA designing a crash-safe update of protected state would invariably place counter advancement last, because advancing first would strand data encrypted under a key the device can no longer regenerate — a predictable design constraint, not a discovery. That argument is respectable but is the point at which '050's defenders will push back hardest (§ 8 below).

---

5. Ground 2 — England (US 2004/0003244 A1 / US 7,421,579 B2) → claims 16 and 17, alone or in view of Ground 1

Claims 16 and 17 (the FIG. 3 embodiment) are the most exposed claims, because the record contains art directed at exactly their problem — efficient rollback protection for many data items sharing one hardware counter.

Motivation. England states its own reason for the per-part-plus-shared-counter design: implementing a hardware secure counter per data item "is obviously costly in terms of hardware," and proliferating counters "may introduce opportunities for security to be thwarted." That is a direct, express teaching to the '050 architecture of one monotone register (MR 112) plus per-part key numbers — and '050's own specification recites the same cost/complexity justification ("the tamper-proof module 102 does not need to recalculate all of the MACs and then re-encrypt all of data when an MR update takes place"). The improvement is the predictable use of known elements (per-item protected records + a shared monotone reference + an aggregate authenticator) according to their established functions.

Claims 16 and 17 also inherit, from the earlier summary's note, an important procedural weakness: they are the claims whose subject matter most closely tracks a cited reference, so they are prime IPR targets. Note one drafting asymmetry: claim 17 recites "a MAC over all of the stored monotonic register counter values," while the specification (FIG. 3) describes "MAC_Kn4 over the MACs that are stored with all of the protected individual parts." Those are two different objects (counter values vs. MACs). That mismatch is explored in § 10.

---

6. Ground 3 — Claim-specific art

• Claim 8 (data is a DRM counter and/or SIM prepaid amount): US 2004/0126093 A1 (Platt, replay prevention in conditional access), US 2003/0007437 A1 (Staring, record carrier for a digital work), WO 2003/081549 A2 (Ericsson, stored-value data objects), and the Ericsson/Smeets dynamic-counter application (US 2002/0038429 A1) together disclose protected usage counters for content and protected prepaid balances. The '050 Background admits both applications are known, which limits the argumentative room.
• Claim 15 (MR in protected flash/EPROM/EEPROM/e-fuse): US 6,836,853 B1, claims 5, 13, 16–17 (flash programming of bit locations; cascading blocks), and see https://patents.google.com/patent/US6836853B1/en.
• Claims 4/11 (distinct integrity and encryption keys): Schneier pp. 357–363 (key separation, MAC keys distinct from encryption keys) plus '919's separate hash and encryption engines.
• The firmware-upgrade / one-time trigger feature in the '050 description (not claimed): JP H07-191836 A (Canon, "Basic operation program upgrade checker") and JP 3644320 B2 (NEC, "Control code reading system") are the closest record art, though since this is unclaimed subject matter it bears only on motivation, not validity.

---

7. Why the combination is "obvious" rather than merely "assembled": the stated-rationale summary

---

8. Where the patent's defenders will fight back (and how strong each point is)

I should be candid that this is not a one-sided case. The following are genuine, articulable non-obviousness positions:

1. The ordering in claim 2 is the invention. Protect-and-store under the next keys before stepping the monotone register, and erase the old copy last, is an atomicity discipline. The references do not recite this three-step order as such. Strength: moderate — but vulnerable to the predictable-design-constraint argument in § 4 (advance the counter first and you can never decrypt your own data again). Under KSR, "the improvement is [no] more than the predictable use of prior art elements according to their established functions."
2. "Old keys cannot be regenerated." The '050 specification makes forward-only key evolution explicit. '919's re-keying does leave the possibility of key retention for old cryptoperiods; it does not teach one-way key evolution. Strength: the strongest technical point — though Lamport 1981, cited by the applicant, is essentially the teaching of non-regenerable sequences, which cuts against it.
3. "Only current and next keys may be referenced." A POSITA might argue that '919's per-page random keys and England's stored parent value solve the same problem by keeping keys/values rather than by eliminating key history. Strength: modest; England's own design achieves a comparable effect by comparing stored-vs-actual counter values.
4. Secondary considerations. I found nothing in the record — no evidence of unexpected results, long-felt but unmet need, failure of others, industry praise, licensing/acquisition nexus, or copying — that would rebut a prima facie case. That omission is itself notable for a patent from a major licensor. As flagged in the earlier summary, I found no litigation, and I cannot confirm or deny licensing; do not assume a licensing-nexus argument is available without evidence.
5. The references were before the Examiner. These are the attorney's own cited references, so the Examiner presumably considered and distinguished them. A successful challenge would likely need either (i) a combination argument the Examiner did not make, or (ii) evidence the Examiner did not have. The England-based attack on claims 16–17 is the most attractive on that ground, because those claims are the ones least evidently covered by the applicant's own disclosure framework and most evidently prefigured by England's per-part/counter-file architecture.

---

9. Anticipated claim-construction inputs (pre-empting the obviousness fight)

Any § 103 analysis of this claim set must fix the following constructions first:

• "pseudo random function (PRE)" in claims 1, 9 and 17 versus "PRF" elsewhere. This is a textual defect on the face of the record (the earlier-generated summary flagged it; I concur). It bears on indefiniteness more than on obviousness, but it matters because a challenger will want the term read as the ordinary PRF (to match Philips/Schneier), while the patentee may argue the granted text controls literally.
• Claim 1's "such that it is possible to generate" both current and next keys is a capability limitation, not a step. Read broadly (the ordinary artisan can increment a counter), it is nearly coextensive with "counter-based key derivation" and adds little. Read narrowly (a structural guarantee of non-regenerability of old keys), it puts claim 1 closer to argument 2 in § 8. This construction drives the entire claim-1 analysis.
• Claim 2's "erasing the verified old data" must be construed against the specification's step 7 ("the old version of the data that was verified in step 2… by using keys MIK_n and MCK_n") — i.e., erasure of the prior version, not of the newly re-protected copy.

---

10. Two additions to the earlier-generated sections

(a) Additional internal inconsistencies (beyond the previously flagged "PRE"/"PRF" and claim-1 scope issues). Read literally, several dependent claims do not track their parents:

• Claims 4 and 11 define the new keys but cite them as "an integrity key (MIK_n)" and "an encryption key (MCK_n)" — the n+1 index is dropped, so the claim as written appears to recite the current keys inside a "new keys" definition. (Claim 11 correctly uses MIK_n+1/MCK_n+1, making the claim-4/claim-11 pair internally inconsistent.)
• Claims 7 and 14 say the protecting step applies encryption "using the MCK_n," again dropping the +1, in a claim that depends from the claim reciting the n+1 keys.
• Claims 12 and 14 recite "wherein said protecting step includes…" in device claims (9/11 lineage), where the parent recites an action ("protect the verified old data and new data if any") rather than a "protecting step."
• Claim 17 recites a MAC "over all of the stored monotonic register counter values," whereas the specification describes the aggregate as a "MAC (shown as MAC_Kn4) over the MACs that are stored with all of the protected individual parts." If the claim is read to require a MAC over counter values, England's parent-counter signature maps onto it even more cleanly; if it is read as the specification's MAC-over-MACs, the claim is still met by England's aggregate signature in substance.

These are § 112(b) issues, not § 103 issues, and — importantly — § 112 indefiniteness cannot be raised in an IPR (35 U.S.C. § 311(b) limits IPR to § 102/§ 103 grounds). They are relevant to a district-court invalidity case or to claim construction in either forum.

(b) A prior-art reference not on the face of the patent. One retrieved document, EP 1 850 256 A1, appears to claim a very similar architecture (sequence of counter values with integrity-protection values generated from a device-specific secret; verification of the current counter value conditioned on success; integrity-protection module secured against modification; implemented in a mobile terminal; counters as software version counters), and its search report cites WO 01/33317 A against claims 1–34. I could not establish EP 1 850 256 A1's priority/publication relationship to 2005-12-01, and it is not in the '050 record's citation lists — so I am not relying on it. If its priority predates 2005-12-01, it would be a materially stronger § 102/§ 103 reference than anything on the patent's face, especially against claim 1. This is the single highest-value item to verify.

---

11. Bottom line

• Independent claims 1 and 9, and dependents 3–7 and 10–15, are vulnerable to a Philips WO 2001/033317 A1 + Intel US 5,757,919 + Intel US 6,836,853 B1 combination, with Schneier and Lamport (both cited by the applicant) supplying the conventionality of PRF-based key derivation, HMAC, key separation, and non-regenerable counter chains. The motivation is strong because all three references address the same problem — security-critical state in attacker-rewritable memory — and all three elements retain their known functions.
• Independent device claims 16 and 17 are the most vulnerable, because US 2004/0003244 A1 (England) discloses the same architecture (per-item protected records stored with the counter value they were protected under, plus an aggregate signature over the collected counter values, in a file that need not be stored securely) for the same purpose (rollback/replay prevention) with an express cost-based motivation for sharing one hardware counter. The gap is that England uses the counter value as signed data rather than as key-derivation input; bridging that gap requires either Ground 1's counter-keyed PRF or a Schneier-type subkey-derivation teaching.
• Claim 8 (DRM counter / SIM prepaid amount) is undermined by the patent's own Background admissions plus Platt, Staring, WO 03/081549 A2 and the same-assignee US 7,043,636 / US 2002/0038429 A1.
• The strongest patentee defenses are the claim-2 ordering (protect-and-store → increment → erase) and the "old keys cannot be regenerated" property. Both are KSR-vulnerable as predictable design choices, but neither is a trivial hurdle, and both depend on claim construction of claim 1's "possible to generate… new keys" language.
• No secondary-considerations evidence appears in the record. Confirming the absence of a licensing or commercial-success nexus would require documents I have not retrieved.

What I could not verify and would need before this analysis could support a filing: full texts of WO 2001/033317 A1 / EP 1312087 B1, US 2003/0007437 A1, GB 2351819 A (I worked from title/assignee/abstract/related-family claims for these); the file history of 11/275,015 (I have not retrieved any Office action, which would show how the applicant distinguished these exact references); the priority date of EP 1 850 256 A1; and any evidence bearing on secondary considerations. Absent those, treat the above as a structured hypothesis set, not a conclusion.

Sources cited: https://patents.google.com/patent/US7681050B2/en (the record and its citation lists); https://patents.google.com/patent/[US5757919A](/patent/US5757919A)/en ; https://patents.google.com/patent/[US6836853B1](/patent/US6836853B1)/en ; https://patents.google.com/patent/US20040003244A1/en and https://patents.google.com/patent/[US7421579B2](/patent/US7421579B2)/en ; https://patents.justia.com/patent/[7421579](/patent/7421579) ; https://patents.google.com/patent/EP1312087B1/en (EP member of WO 2001/033317 A1); https://patents.google.com/patent/[US7043636B2](/patent/US7043636B2)/en and https://www.freepatentsonline.com/y2002/0038429.html ; https://patentimages.storage.googleapis.com/2f/7e/6e/80ca2e93490e08/US7043636.pdf and .../EP1325401B1.pdf ; https://patentimages.storage.googleapis.com/6a/05/40/1f94b19b2f49cf/EP1850256A1.pdf (date unverified — not relied upon).