US 10637869

US 10,637,869 B2 — Summary

Important caveat up front: I could not confirm any 2026 CAFC docket or active USPTO litigation record naming US 10,637,869 in the searches I ran. The Google Patents record for this patent carries a "Family has litigation" flag pointing to a Darts‑ip family page (family ID 38608993), but my search attempts to retrieve that family's case list were cut off and returned no usable docket data. Treat any litigation statement below as unverified. I also did not find this patent in reported BlackBerry v. Facebook or comparable 2026 CAFC matters. Do not treat the absence as proof that no case exists — it means I lack authoritative confirmation.

Bibliographic data (per the granted patent / Google Patents record)

Continuity chain (same family): US 11/735,055 → US 8,688,978 → US 14/170,213 → US 9,667,634 → US 15/595,542 → US 10,097,559 → US 16/153,676 → US 10,637,869 → US 16/852,179 → US 12,407,692. All share the 2006‑04‑13 priority.

⚠️ Do not conflate this family with the similarly titled US 11,063,958 ("Method and apparatus for providing an adaptable security level…"), which lists a 2003‑07‑07 priority and is a distinct family, nor with Struik's "synchronizing an adaptable security level" family (US 8,640,253 / US 9,253,161, priority 2004‑08‑19). Different patents, different priority.

Abstract (verbatim)

A method of communicating in a secure communication system, comprises the steps of assembling a message at a sender, then determining a frame type, and including an indication of the frame type in a header of the message. The message is then sent to a recipient and the frame type used to perform a policy check.

Independent claims — plain language

Claim 1 — sender-side device. A first device (hardware processor + non‑transitory storage medium holding instructions) is programmed to:

1. assemble a data stream containing a frame that has a header and data;
2. determine a security level for that frame;
3. put two things in the header: an indication of a frame type and an indication of the security level; and
4. forward the frame to a second device.

The claim then defines the acceptance rule from the recipient's standpoint: the frame type is associated with a policy that specifies a minimum security level for that frame type; the second device accepts the frame if the transmitted security level meets that minimum, and does not accept it if the security level falls short.

Claim 10 — recipient-side device. A second device is programmed to:

1. receive, from a first device, a frame with a header and data, the header carrying an indication of frame type and an indication of security level;
2. determine the frame type from the header;
3. correlate the frame type to a policy, where the policy indicates a minimum security level for that frame type; and
4. decide, based on the policy, whether to accept the frame type according to whether the security level meets the minimum.

Structural note / possible drafting artifact: claim 2 depends from claim 1 but recites operations performed by the second device ("wherein the second device: receives the frame; determines the frame type…; and correlates…"). It reads like a method claim converted into apparatus form. Dependent claims 3–7 also depend from claim 1 but describe second‑device behavior; claims 8 and 9 depend directly from claim 1 (footer error‑code bits; header containing a key identifier, a key representation, and an originator). Claims 11–17 mirror the same subject matter as dependents of claim 10. Only claims 1 and 10 are independent.

Dependent-claim subject matter (both sets)

• Accept/reject on policy pass/fail (claims 3, 11)
• Header includes a key representation; policy indicates an acceptable frame type for that key (claims 4, 12)
• Policy identifies frame types vulnerable to attack for certain combinations of security features; reject if such a combination appears (claims 5, 13)
• Security level conveyed as one or more security bits that the recipient extracts (claims 6, 14)
• Policy implemented as a look‑up table correlating frame type to an attribute (claims 7, 15)
• Frame includes a footer with error‑code bits (claims 8, 16)
• Header includes key identifier, corresponding key representation, and originator used in determining acceptability (claims 9, 17)

Specification context relevant to the claims

The written description supplies more than the claims capture: per‑frame security bits (security mode + integrity‑level bits mapping to e.g. 0/32/64/128‑bit integrity), a layered network stack (APL/NWK/MAC/PHY) with delegation of cryptographic processing to lower layers, ACK‑based feedback to synchronize the recipients' expected protection level SEC₀ (FIGS. 7–8), and an "ExemptSet"/"OverrideSEC(m)" mechanism letting a not‑yet‑keyed device bypass the minimum‑security check during initialization (FIGS. 12–13). Those exemption and synchronization aspects are described but are not recited in the two independent claims as issued — so the granted claim scope centers on the frame‑type‑driven minimum‑security policy check, not on the exemption feedback scheme.

What I can and cannot attest to

• Well supported by the authoritative full text: title, inventor, assignee chain, application number, filing date, priority date, issue date, abstract, full claim set, and the specification content summarized above.
• Not verified: any 2026 CAFC appeal, ITC action, or district‑court case specifically asserting US 10,637,869; the Darts‑ip "family litigation" flag's underlying case list; and the current legal status beyond the "Active" indication on Google Patents. I did not locate a docket and will not speculate about one.

I'll research litigation involving US Patent 10637869. Let me run several searches.

Let me search more specifically for this patent family and related litigation.

Let me search the litigation portals directly.

Summary of findings

I could not confirm any litigation specifically asserting U.S. Patent No. 10,637,869. Based on the sources I was able to search (Google Patents, general web search, and search-engine hits from PACER/CourtListener/Docket Alarm/Unified Patents and the PTAB), no complaint, ITC action, or PTAB proceeding expressly identifying US 10,637,869 as an asserted or challenged patent surfaced.

I want to be transparent about two things before the detail:

1. My searching hit a tool limit partway through (the final three queries did not execute), so this is not an exhaustive clearance-level check. It is a good-faith survey that found nothing.
2. I am reporting only what I actually found. I am not going to attribute a case number, court, or outcome to this patent that I cannot ground in a source.

---

The patent itself (authoritative per the patent text provided)

Litigation indicator on the family (not a case identification)

The Google Patents record for US 10,637,869 carries a "Family has litigation — First worldwide family litigation filed" flag, linking to a Darts-ip record for family ID 38608993 (https://patents.darts-ip.com/?family=38608993). This is a family-level notice only. It tells us that some member of this patent family (which includes US 8,688,978; US 9,667,634; US 10,097,559; US 11,063,958; US 12,407,692, plus EP 2005636 B1, JP 4911736 B2, KR 101519151 B1, CN 101496338 B, CA 2941216 C, ES 2556623 T3, WO 2007118307 A1) has been litigated somewhere. It does not identify the court, parties, case number, or dates, and it does not establish that the '869 patent itself was ever asserted.

Related BlackBerry litigation — NOT this patent (do not conflate)

My searches surfaced several BlackBerry/Certicom cases. None of them is shown to involve US 10,637,869, and I list them only to avoid confusion:

• BlackBerry Limited v. Facebook, Inc., WhatsApp Inc., Instagram, Inc. — C.D. Cal., No. 2:18-cv-01844 GW (KSx) (filed ~2018). Patents in suit included US 8,279,173; US 8,825,084; US 8,326,327; US 8,429,236 and others. Resolved by stipulated dismissal of all claims/counterclaims (Feb. 2021); an appeal on one patent was affirmed (Fed. Cir. No. 2020-1256, Fed. Cir. R. 36, Dec. 2020).
• Affinity Labs of Texas, LLC v. BlackBerry Corp./BlackBerry Ltd. — N.D. Cal., No. 3:18-cv-03194.
• Uniloc USA, Inc. et al. v. BlackBerry Corp. — (Uniloc asserting US 7,020,106).
• MobileMedia Ideas LLC v. Research In Motion — N.D. Tex., No. 3:11-cv-02353-N.

None of these dockets, as found, name US 10,637,869.

Conclusion

• Known litigation expressly involving US 10,637,869: none found.
• Caveat: the patent family (Darts-ip family 38608993) is flagged as having had at least one litigation, but the source does not identify it, and I could not tie any identified case to this specific patent number.

Recommended verification steps (since I could not complete them)

To close this out with confidence, check directly, as these are the authoritative sources for asserted-patent identification:

1. Unified Patents litigation portal — https://portal.unifiedpatents.com/litigation — search the patent number and its family members.
2. Darts-ip — https://patents.darts-ip.com/?family=38608993 (the family litigation record Google points to).
3. CourtListener / RECAP — https://www.courtlistener.com — search "10,637,869" across dockets and opinions.
4. PACER — docket-level confirmation for any candidate case.
5. USPTO PTAB (PTAB E2E / PTABIS) — for any IPR/PGR/CBM challenging the '869 patent; a challenge there would also be relevant.
6. USITC EDIS — https://edis.usitc.gov — for any Section 337 investigation naming the patent.

If you'd like, I can attempt these targeted searches again (the last three queries were cut off by a step limit), or focus on a specific family member such as US 11,063,958 or US 12,407,692, which are more likely to have been asserted in later filings.

PTAB / AIA Trial Landscape — US 10,637,869 B2

"Method and apparatus for providing an adaptable security level in an electronic communication" — Marinus Struik; current assignee BlackBerry Limited (originally Certicom Corp.); priority 2006-04-13; granted 2020-04-28

---

Proceedings overview

Total AIA trial proceedings on file: 0 (zero). Breakdown: 0 active, 0 with claims invalidated, 0 with claims sustained, 0 settled, 0 institution-denied. The structured "PTAB proceedings on file" block sourced from the USPTO Open Data Portal returns no AIA trial proceedings for this patent as of the most recent ingest, and my independent web searches surfaced no IPR, PGR, or CBM petition, institution decision, or Final Written Decision naming U.S. Patent No. 10,637,869. The defensive posture this yields is not "the patent is hardened by surviving PTAB scrutiny" — it is "the patent has never been PTAB-tested at all." That is a materially different posture: all 17 claims sit before the Board as virgin territory, and no § 315(e)(2) estoppel has been generated against anyone.

Confidence note: I did not find, and am not aware of, any AIA trial on this patent. I searched by patent number, by patent title, by inventor/family (US 8,688,978 / 9,667,634 / 10,097,559 / 12,407,692), and by assignee. Because I could not complete an exhaustive PTAB E2E and Docket Alarm sweep within the research budget, treat "zero proceedings" as high confidence but not certified — the ODP block is the canonical source and it is empty. If a recently filed petition exists and has not been indexed, it would appear at PTAB E2E / PTAB Center before it surfaces elsewhere.

---

Per-proceeding detail

No proceeding entries are possible. I will not manufacture proceeding numbers, panels, or dispositions. For completeness, the following are the near misses that a keyword search throws up, and why none of them is a proceeding on this patent:

---

Strategic summary

Claim status: every claim is UNTESTED. The patent carries 17 claims — claims 1–9 drafted as a "first device" (transmitting side) and claims 10–17 as a "second device" (receiving side). Claim 1 requires assembling a frame having a header and data, determining a security level, incorporating an indication of a frame type and an indication of the security level in the header, and forwarding the frame, where the frame type is associated with a policy that indicates a minimum security level for the frame type. Claim 10 is the mirror-image recipient-side claim. Claims 4–7, 9, and 12–17 add key-representation, attack-vulnerability, security-bit-extraction, look-up-table, footer-error-code, and originator limitations. Nothing has been canceled, and nothing has been confirmed. There is no FWD to quote a disposition from.

Estoppel landscape: essentially clean, which cuts both ways. Because no IPR/PGR was ever instituted against this patent, no petitioner is subject to § 315(e)(2) estoppel, and a defendant today is likewise free of any estoppel of its own — it can raise § 102, § 103, and § 112 grounds in district court, in an IPR, or both, without the "raised or reasonably could have raised" bar attaching. The flip side: there is no petitioner-side work product, no Board claim construction, and no institution decision narrowing the claim scope that a defendant could borrow. Any challenge is a first-principles exercise. Conversely, because the patent was never tested, there is also no adverse estoppel running against BlackBerry that would constrain its infringement theories — the Board has never construed "frame type," "policy," or "minimum security level" for this family.

Pattern signals. No repeat-petitioner pattern (no petitioner at all). No PTAB appeal history (no FWD to appeal). No defensive aggregator — I found no Unified Patents or RPX filing, though Unified maintains a public portal entry for a sibling in the broader BlackBerry/Certicom "adaptable security level" portfolio (US 10,341,356, the 2004-priority branch), which suggests the family has been on the defensive-monitoring radar even if no challenge issued. One structural reality is dispositive for a defendant: this is a late-filed continuation in a 2006-priority family (application 16/153,676, filed 2018-10-05). Google Patents lists an anticipated expiration of 2027-04-13 for US 10,637,869, i.e., the enforceable runway is roughly six-and-a-half months from today's date (2026-09-30). The family does, however, include a live later continuation, US 12,407,692 B2 (granted 2025-09-02, same 2006 priority) — so any invalidity or design-around work should be performed against the whole family, not just the '869 patent, or you risk re-litigating the same disclosure against the newer continuation.

---

Recommended next steps

1. State the absence clearly in any opinion or invalidity analysis. There is no PTAB decision to cite, no IPR to leverage, and no estoppel to plan around. Do not let an adversary's demand letter imply the patent has been "upheld" by the Board — it has not been examined by the Board at all.
2. Run a fresh PTAB E2E / PTAB Center query on the whole family before relying on this memo. Search the patent numbers and their continuation lineage: US 8,688,978, 9,667,634, 10,097,559, 10,637,869, and 12,407,692, plus the 2004-priority sibling branch (US 10,341,356 → 11,063,958 → 11,563,747). A newly indexed petition on this patent would be the single most important update to this landscape.
3. Exploit the short runway and the continuation risk. Given the ~2027-04-13 anticipated expiration, weigh whether a stay-plus-IPR strategy is even worth the cost, versus a straight § 101 / § 112 and § 102/§ 103 defense in district court — but confirm the term with the USPTO Patent Center file wrapper, since the '869 file has a terminal-disclaimer / PTA interaction (the parent US 8,688,978 shows an active date of 2030-03-05 in Google's data, which suggests PTA that may or may not flow through).
4. If you do file an IPR, it must be against the live claims of the '692 continuation as well, and the petition should target the claim-1/claim-10 "frame type + security level + policy minimum" combination — the only independent claims — with dependent claims 4–7 and 9, 12–17 challenged in the alternative. There is no prior Board construction to work from, so propose your own constructions of "frame type" and "policy" and support them with the 2006-04-13 priority specification.
5. Link the record you rely on. For any future opinion: USPTO PTAB decisions and E2E filings at https://ptacts.uspto.gov/ptacts/; Federal Circuit dispositions via CourtListener and the CAFC docket; patent family/claims at Google Patents US10637869B2.

I'll research this patent's ownership chain before drafting. Let me run several targeted searches.

Good leads. Let me dig into the specific assignment records, the BlackBerry patent portfolio sales, and any litigation/assertion history.

Assignment & Ownership Analysis — US 10,637,869 B2

Method note / coverage caveat. The USPTO Assignment Center (https://assignmentcenter.uspto.gov/) is a JavaScript single-page app that my retrieval tools could not render; Assignment Search (https://assignment.uspto.gov/patent/index.html) returned no server-side record for this patent number in my queries. I therefore reconstructed the chain from (a) Google Patents Legal Events for US10637869 and (b) a foreign sibling register (Irish Patent Register, EP 2005636 / app 07719535.2, family 38608993) that records the same underlying Deed of Assignment with an explicit execution date. Reel/frame numbers and the recorded correspondent attorney were not retrievable through my tools and are flagged as not retrieved throughout. Any field I could not verify is marked as such rather than inferred. Search URL for manual verification: https://assignment.uspto.gov/patent/index.html (query patent number 10637869) and https://patents.google.com/patent/US10637869/en.

---

Inventors

Unusual-pattern check: No anomaly. Struik did not depart the original assignee within 12 months of filing — he remained a Certicom cryptographer after RIM's 2009 acquisition and appears as inventor on later Certicom/BlackBerry family members (e.g., US 11,063,958, applicant Certicom Corp., assignee BlackBerry Limited). There is no inventor-exodus precursor to a fire-sale here.

---

Original assignee

• Entity named on the issued patent (Google Patents front page): BlackBerry Ltd (original and current assignee). However, the substantive original assignee is Certicom Corp., the applicant/employer on the family (see sibling US 11,063,958: "(71) Applicant: Certicom Corp., Mississauga (CA); (73) Assignee: BlackBerry Limited, Waterloo (CA)"). BlackBerry Ltd appears as the patent's assignee because the Certicom chain was consolidated into BlackBerry by the 2019 Deed of Assignment before US10637869 issued.
• Primary line of business (Certicom): Elliptic Curve Cryptography — commercial security toolkits (Security Builder family), Certicom Device CA, and ECC licensing; founded 1985 as Mobius Encryption; ~350 patents; customers included IBM, Oracle, Motorola, NSA.
• Did it ship a product embodying the claims? Yes — Certicom shipped commercial cryptographic software/hardware products and licensed ECC implementations; its technology was embedded in RIM/BlackBerry products.
• Current status: Acquired. Research In Motion (RIM) acquired Certicom in 2009 for ~US$106.5M after a hostile bid and bidding war with VeriSign (deal announced Feb 2009; Certicom became a wholly owned RIM subsidiary). RIM renamed itself BlackBerry Limited in 2013. BlackBerry Limited is operating (public; NYSE: BB), now a cybersecurity/IoT software company — not in bankruptcy. Certicom as a separate brand/operation was folded into BlackBerry.

---

Assignment timeline

Records below are the reassignment entries carried on Google Patents Legal Events for US10637869, cross-checked against the Irish register entry for the same family. No reel/frame or correspondent data was retrievable — treat those fields as open items for manual Assignment Center retrieval.

• Executed ~2006–2007 (execution date not retrieved) / recorded 2020-01-08 — Reel not retrieved

  • Conveyance: Assignment (original inventor assignment)
  • Assignor: Struik, Marinus
  • Assignee: Certicom Corp.
  • Correspondent: not retrieved (cannot confirm recurrence)
  • Context: Capture of the inventor's rights by his employer (original chain of title), recorded late as part of a family-wide title cleanup.

• Executed 2019-09-30 (Deed of Assignment date per Irish register, same family) / recorded 2019-10-02 — Reel not retrieved

  • Conveyance: Assignment ("Deed of Assignment")
  • Assignor: Certicom Corp., 4701 Tahoe Boulevard, Tahoe A, 6th Floor, Mississauga, Ontario L4W 0B5, Canada
  • Assignee: BlackBerry Limited, 2200 University Avenue East, Waterloo, Ontario N2K 0A7, Canada
  • Correspondent: not retrieved (cannot confirm recurrence)
  • Context: Internal corporate reorganization / title consolidation — Certicom (a BlackBerry subsidiary since the 2009 RIM acquisition) formally deeded the family to the parent.

• Recorded 2020-01-08 — Reel not retrieved

  • Conveyance: Assignment of assignors' interest (listed separately on Google Patents)
  • Assignor: Certicom Corp.
  • Assignee: BlackBerry Limited
  • Correspondent: not retrieved
  • Context: Confirmatory/corrective recording of the same Certicom→BlackBerry transfer (appears in addition to the 2019-10-02 entry — a housekeeping duplicate, not a third-party transfer).

No post-issuance transfer to any NPE, LLC, or litigation vehicle appears in the recorded chain. The recorded chain is entirely Certicom/BlackBerry internal.

---

Timeline diagram

timeline
    title Ownership of US 10637869
    2006 : Priority provisional filed
    2007 : Parent filed by Certicom
    2009 : Certicom acquired by RIM
    2013 : RIM renamed BlackBerry
    2018 : Continuation application filed
    2019 : Certicom assigns to BlackBerry
    2020 : Patent issued to BlackBerry
    2023 : BlackBerry announces patent sale to Malikie

---

NPE / troll-pattern signals

1. Shell-entity transfer — Not present. Both links run between operating entities: Struik → Certicom Corp. → BlackBerry Limited. No "IP/Holdings/Licensing/Ventures" LLC, no registered-agent address, no single-purpose Delaware/Texas entity appears in the recorded chain (Google Patents Legal Events, recorded 2019-10-02 and 2020-01-08).

2. Known asserter in the chain — Not present. No assignee matches the enumerated NPE lists (Acacia, Marathon, IV, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation, Spangenberg entities). The chain terminates at BlackBerry Limited. Caveat: BlackBerry's 2023 counterparty, Malikie Innovations Ltd. (subsidiary of Key Patent Innovations Ltd., an "IP monetization" firm), is asserter-adjacent — but I found no confirmation that US10637869 was included in that sale (see #7).

3. Repeat correspondent across the chain — Unclear / not retrievable. Correspondent of record is the key tell here, and I could not extract it. This signal cannot be assessed on available data and should not be scored. Manual step: pull reel/frame + correspondent from the Assignment Center for the 2019-10-02 and 2020-01-08 recordings and check whether one attorney/firm handled every link.

4. Cascading transfers — Not present. There are not multiple chained LLC hops. The 2019-10-02 / 2020-01-08 cluster is a two-link internal consolidation (Certicom→BlackBerry, plus a confirmatory re-recording), not a cascade of unrelated shells. No common-principal LLC pattern is evidenced.

5. Pre-litigation transfer — Not present / unclear. No confirmed infringement suit naming US10637869 was located. Note that Google Patents flags the wider family as "Family has litigation — first worldwide family litigation filed" (Darts-IP family 38608993, https://patents.darts-ip.com/?family=38608993) — but I could not confirm the parties or the specific patent, so I do not treat this as a pre-litigation-transfer finding. Verify before scoring.

6. Bankruptcy fire-sale — Not present. BlackBerry has not filed Chapter 7/11. Its 2022–2023 patent divestitures are strategic monetization transactions, not insolvency sales.

7. Privateering — Unclear. BlackBerry agreed (announced 2023-03-21) to sell ~32,000 non-core patents to Malikie Innovations Ltd, an IP-monetization vehicle, while retaining a license-back and royalty interest — a classic monetization/privateering structure if the patent is included. However, (i) the sale expressly excluded assets supporting BlackBerry's current core business and its ~2,000 SEPs, and (ii) later members of this same 2006-04-13 family still issued to BlackBerry Limited (US 11,063,958, 2021; US 12,407,692, issued 2025-09-02). That strongly suggests the '869 family was retained, but I could not confirm inclusion/exclusion of US10637869 specifically. Score as unclear.

8. Defensive aggregator (anti-NPE) — Not present. Chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN.

---

Verdict

Insufficient data — for an NPE/assertion determination.

Justification: The recorded chain contains zero NPE signals: it is an entirely internal, operating-company chain — inventor Struik → Certicom Corp. (recorded 2020-01-08) and Certicom Corp. → BlackBerry Limited (Deed of Assignment executed 2019-09-30, recorded 2019-10-02, with a confirmatory re-recording 2020-01-08) — with both entities being operating businesses (Certicom a BlackBerry subsidiary since 2009). I am withholding an "Operating-company assertion" verdict because I could not confirm that BlackBerry is actually asserting this patent (no suit naming US10637869 was verifiable), and I am withholding an outright "no-NPE" clearance because (a) I could not retrieve the reel/frame and correspondent fields that the analysis depends on, and (b) BlackBerry's 2023 sale to monetization firm Malikie Innovations leaves current ownership of this family member unconfirmed. If the analyst treats the recorded USPTO chain as complete and current, the correct reading is that this patent remains with an operating-company owner (BlackBerry Limited) and shows no NPE pattern.

Verification links:

• Assignment Search: https://assignment.uspto.gov/patent/index.html (search 10637869)
• Assignment Center: https://assignmentcenter.uspto.gov/
• Google Patents legal events: https://patents.google.com/patent/US10637869/en
• Family litigation flag: https://patents.darts-ip.com/?family=38608993

Open items to close the record manually: (1) reel/frame for the 2019-10-02 and 2020-01-08 recordings; (2) correspondent attorney/firm on both, to test signal #3; (3) whether US10637869 was included in the BlackBerry→Malikie Innovations sale (regulatory/HSR filings or the assignment of record post-2023); (4) identity of the "family litigation" parties flagged by Darts-IP, to test signal #5.

I'll research this patent's prior art. Let me run targeted searches, starting with the patent record itself and its cited references.

Let me pull more detail on the most relevant cited references and check the USPTO record.

Prior-Art Analysis — US 10,637,869 B2

1. What I could and could not verify (read this first)

Requested: search the USPTO database for patent number 10637869 (interpreted literally as US 10,637,869 B2), and analyze each cited reference.

What I actually obtained:

• I confirmed the patent's bibliographic record and its face‑of‑patent "References Cited" list (107 items) from the authoritative full text you provided (Google Patents mirrors the USPTO-printed citations) and from a corroborating search hit at https://patents.google.com/patent/US10637869.
• I retrieved the full front‑page text and abstracts of several of the highest‑relevance cited references (Struik US 2005/0076197; Struik US 2004/0136527; IBM US 7,010,681; Cisco US 2006/0112431 / US 7,721,323).

What I could not obtain (be aware of these gaps):

• I hit a tool/step limit before running the actual USPTO Patent Public Search full‑text query and the PTO‑892 / office‑action file wrapper. Therefore I cannot tell you which references the examiner actually used in a §102 rejection, nor the substance of any rejection. Everything below is my own forward‑looking analysis of the cited references, not a report of examiner findings.
• I did not verify the full text of every one of the 107 citations. For the ones I could not open, I flag my description as provisional.

Important legal-framework note: The patent's earliest priority is 2006‑04‑13 (pre‑AIA). So the applicable statute is pre‑AIA 35 U.S.C. §102(a)/(b)/(e) (and §103). The §102(b) one‑year critical date is 2005‑04‑13. Because this is a continuation, the substantive §102 rejections (if any) would have occurred in the parent applications (US 8,688,978 / 9,667,634 / 10,097,559), not in the '869 prosecution.

Caution on identifiers (per your strict rule): Do not confuse US 10,637,869 with the similarly titled US 11,063,958 (Struik, filed from the 2003‑priority line). Also don't confuse with the "synchronizing" family (US 8,640,253 / US 9,253,161, priority 2004‑08‑19). These are distinct families.

---

2. The independent claims I am mapping against (from the authoritative text)

The novelty pivot is the combination of (i) an in-header frame-type indication and (ii) a policy that keys a minimum security level to the frame type.

---

3. Most relevant cited prior art — detail

R1 — US 2005/0076197 A1 (Marinus Struik), "Method and apparatus for providing an adaptable security level in an electronic communication"

• Citation: US 2005/0076197 A1; Appl. No. 10/885,115.
• Dates: filed 2004‑07‑06; priority 2003‑07‑07 (provisional 60/484,656); published 2005‑04‑07. Later granted as US 8,862,866 B2 (family continues to US 9,419,983 and US 11,063,958).
• Assignee: Certicom Corp. (now BlackBerry) — same inventor as the '869 patent.
• Brief description: Discloses per‑frame security bits (a security‑mode bit for encryption on/off and two integrity bits for 0/32/64/128‑bit integrity) carried in the frame control; the recipient extracts the bits, decrypts/authenticates, and checks the observed security level against a minimum SEC₀, rejecting if unmet. Also discloses ACK‑based feedback of SEC₀ and message‑dependent SEC₀.
• §102 potential: Strong §102(b) art (published 2005‑04‑07, before the 2005‑04‑13 critical date). It discloses essentially every element of claims 1/10 and 6/14 except the "frame type" indication and the frame‑type‑keyed policy. The word "frame type" appears only in the background discussion of prior practices, not as a header field the recipient uses. So it does not, standing alone, anticipate claims 1 or 10 as issued; it is the closest reference and is highly probative. It would anticipate a broader hypothetical claim (assemble frame → determine security level → put security level in header → send → recipient checks against a minimum), and it squarely anticipates claims 6 and 14 (security‑level bits extracted by the recipient). Source: https://patents.google.com/patent/US20050076197

R2 — US 2004/0136527 A1 (Marinus Struik), "Method and apparatus for encoding security status information"

• Citation: US 2004/0136527 A1.
• Dates: priority 2002‑12‑04; published 2004‑07‑15.
• Assignee: Certicom Corp. (same inventor).
• Brief description: Compresses/excises security status information in low‑rate wireless messages — encodes a frame counter and sequence counter compactly, and places a key identifier and frame/sequence counters in the message with reduced overhead.
• §102 potential: §102(b) art (published >1 yr before the priority date). Relevant to the "header carries a key identifier" limitations of claims 9/17 and marginally to claims 1/10 (security metadata in header). Not anticipatory of claims 1/10.

R3 — US 2006/0112431 A1 (Finn & Smith; Cisco), "Method and system for including network security information in a frame"

• Citation: US 2006/0112431 A1; Appl. No. 10/996,101; granted as US 7,721,323 B2 on 2010‑05‑18.
• Dates: filed 2004‑11‑23; published 2006‑05‑25.
• Assignee: Cisco Technology, Inc.
• Brief description: Inserts network security information (a User Group Identifier / security group tag) into the overhead of a frame, together with frame security information; a receiving device applies policy (UGPL – user group permissions list) based on the tag. FIG. 4D expressly depicts "a frame with network security information and a frame type field in overhead of the frame."
• §102 potential: The publication date (2006‑05‑25) is after the '869 priority, so not §102(a)/(b). But its filing date (2004‑11‑23) predates the '869 invention, making it pre‑AIA §102(e) prior art ("by another"). It discloses a frame-type field in frame overhead plus in‑frame security information and policy‑based enforcement — probative against claims 1/10 and against claims 4/12 (key/group‑based acceptable frame type) and claims 7/15 (table‑based policy correlation). Its "policy" is a group permissions policy, not a "minimum security level for the frame type," so it is best used in §103 combination. Source: https://patents.google.com/patent/US20060112431

R4 — US 2005/0097357 A1 (Michael R. Smith; Cisco), "Method and apparatus for providing network security using security labeling"

• Citation: US 2005/0097357 A1.
• Dates: filed 2003‑10‑29; published 2005‑05‑05.
• Assignee: Cisco Technology, Inc.
• Brief description: Applies a security label to frames (layer‑2 security labeling) and compares the label to a stored policy to decide handling of the frame.
• §102 potential: Published 2005‑05‑05 — after the 2005‑04‑13 critical date, so not §102(b); it is §102(a)/(e) art (filed 2003, by another). Relevant to the "policy correlated to a frame attribute" concept (claims 1/7/10/15). Not anticipatory of the full frame‑type‑minimum‑security‑level limitation.

R5 — US 7,010,681 B1 (Fletcher, Kaminsky, Kessler; IBM), "Method, system and apparatus for selecting encryption levels based on policy profiling"

• Citation: US 7,010,681 B1; Appl. No. 09/240,387.
• Dates: filed 1999‑01‑29; granted 2006‑03‑07.
• Assignee: IBM Corp.
• Brief description: Selects encryption/security levels dynamically based on a predefined policy profile. Security tags in a document serve as keys into a security database; content is filtered/encrypted (or withheld) according to the policy and user/device capabilities.
• §102 potential: Granted 2006‑03‑07 — before the priority date but less than one year before it, so not §102(b); it is §102(a)/(e) art (filed 1999). It discloses the "policy specifies a minimum security level" concept (element of claims 1/10) and a table/database‑driven policy (claims 7/15), but at the document/section granularity rather than frame‑type granularity. Best used under §103. Source: https://patents.google.com/patent/US7010681

R6 — US 6,754,214 B1 (Dunti et al.), "Communication network having packetized security codes and a system for detecting security breach locations within the network"

• Citation: US 6,754,214 B1.
• Dates: priority 1999‑07‑19; granted 2004‑06‑22.
• Assignee: Dunti, LLC / Dunti Corporation.
• Brief description: Network in which packets carry security codes that nodes use to enforce/propagate security and to detect breach locations. (Related Dunti patents in the same list: US 6,654,346 B1 and US 6,724,243 B1.)
• §102 potential: §102(b) art (granted 2004‑06‑22, before the critical date). Potentially relevant to claims 1/10 insofar as it places a security code in a packet/frame. Provisional description — I could not open the full text.

R7 — US 6,292,900 B1 (Sun Microsystems), "Multilevel security attribute passing methods, apparatuses, and computer program products in a stream"

• Citation: US 6,292,900 B1.
• Dates: priority/filed 1996‑12‑18; granted 2001‑09‑18.
• Brief description: Passes multilevel security attributes within a data stream so downstream components honor them.
• §102 potential: §102(b) art. Relevant to the notion of carrying a security-level attribute in a stream/frame (claims 1/10). Not a frame‑type‑keyed policy.

R8 — US 5,832,228 (Itt Industries), "System and method for providing multi-level security in computer devices utilized with non-secure networks"

• Dates: priority 1996‑07‑30; granted 1998‑11‑03. §102(b) art. Multi‑level security enforcement between secure/non‑secure domains. General background art against the "security level" concept.

R9 — US 2004/0223615 A1 (Dhawan et al.), "Methods and apparatus for multi-level dynamic security system"

• Dates: filed 2003‑04‑09; published 2004‑11‑11. §102(b) art. Dynamic multi‑level security; germane to claims 1/10 conceptually but not to frame‑type policy.

R10 — US 2006/0112431's sibling and the Cisco labeling family

See R3/R4.

R11 — EP 1,320,010 A2 (Pervasive Security Systems, Inc.), "Secured data format for access control"

• Dates: published 2003‑06‑18 (priority 2001‑12‑12). §102(b) art. Defines a secured data format in which content is labeled and access is controlled by policy. Relevant to "policy‑based acceptability of a formatted frame."

R12 — US 2004/0028409 A1 (Kim; Samsung), "Method for transmitting security data in Ethernet passive optical network system"

• Dates: filed 2002‑08‑07; published 2004‑02‑12. §102(b) art. Transmits security data as fields in Ethernet frames — relevant to claims 1/10 (security data in a frame header). Provisional description.

R13 — US 2004/0010691 A1 (Nelson), "Method for authenticating digital content in frames having a minimum of one bit per frame reserved for such use"

• Dates: filed 2002‑07‑15; published 2004‑01‑15. §102(b) art. Reserves per‑frame bit(s) for authentication — relevant to the "security bit(s) in the frame" limitations (claims 6/14). Provisional description.

R14 — US 2005/0081032 A1 (Struik), "Method and apparatus for synchronizing an adaptable security level in an electronic communication"

• Dates: priority 2003‑08‑19; published 2005‑04‑14. Because 2005‑04‑14 is one day after the 2005‑04‑13 critical date, this is §102(a)/(e) art (not §102(b)). Same inventor, sibling family; discloses ACK‑based synchronization of the minimum security level. Relevant background.

R15 — US 2006/0064736 A1 (Ahuja et al.), "Apparatus, system, and method for asymmetric security"

• Dates: filed 2004‑09‑23; published 2006‑03‑23. §102(a)/(e) art. Asymmetric security treatment of frames. Background.

---

4. Summary table — §102 exposure of the cited references

---

5. Bottom line on §102

• My assessment: No single cited reference appears to anticipate independent claims 1 or 10 in their entirety. The claimed pivot — a header frame‑type indication combined with a policy that maps that frame type to a minimum security level — is not shown by any one of the references I could inspect. The closest reference, R1 (US 2005/0076197 A1, Struik), discloses the in‑header security level and the minimum‑level check but not the frame type; R3 (Finn/Cisco) discloses a frame‑type field and in‑frame security info but not a per‑frame‑type minimum security level.
• Where §102 risk is real: the dependent limitations — the security‑bit extraction (claims 6/14) is squarely shown by R1; keys/labels in the header (claims 4/12, 9/17) are shown by R1/R2/R4. Those dependents are the most §102‑exposed.
• Where §103 risk is real: the combination of R1 (security level + minimum check) with R3 (frame‑type field) or R5 (policy‑driven minimum encryption level) would be the natural obviousness attack on claims 1/10.
• Caveat repeated: I did not retrieve the examiner's actual §102/§103 rejections, so treat the above as my independent analysis, not a record of what the USPTO did. The '869 patent issued with these references of record, which itself suggests the examiner did not find them anticipatory of the issued claims.

---

6. How to close the remaining gaps (authoritative sources I could not reach)

1. USPTO Patent Public Search — https://ppubs.uspto.gov — run the full‑text query for "10,637,869" and view the References Cited and the file wrapper (PTO‑892, Office Actions).
2. USPTO Patent Center — https://patentcenter.uspto.gov — application 16/153,676 file history, and the parent applications (11/735,055; 14/170,213; 15/595,542) where substantive rejections occurred.
3. USPTO Patent Assignment — https://assignment.uspto.gov — confirm the Certicom → BlackBerry chain.
4. For full text of R6, R9–R13, pull the PDFs directly from patentimages.storage.googleapis.com (linked from each Google Patents page) to confirm my provisional descriptions.

If you'd like, I can return to the file-wrapper/Office-Action track (rather than the face‑of‑patent citations) and report the examiner's actual §102/§103 formulation for the parent applications, which is where any real anticipation finding would live.

I'll ground this obviousness analysis in the actual prior-art references listed on the patent, focusing on the most material ones. Let me pull details on the key references.

Obviousness Analysis — US 10,637,869 B2 under 35 U.S.C. § 103

Note: I build on the claim set and specification analysis already produced and do not repeat it. This analysis is grounded in (a) the reference list on the face of US 10,637,869 ("Citations (107)" / "Family Cites Families (53)") and (b) the full text of the most material references retrieved below. Where I have only the title/abstract of a reference, I say so.

---

1. Governing framework

Effective filing date / statute. US 10,637,869 claims priority to 2006‑04‑13 (provisional 60/791,434). The pre‑AIA version of § 103 therefore applies; the AIA first‑inventor‑to‑file amendments are irrelevant. Invalidity must be proven by clear and convincing evidence in litigation; before the Office the standard is a preponderance with claims given their broadest reasonable interpretation.

Claim scope (from the claim set already summarized). Independent claims 1 and 10 are apparatus claims whose only substantive limitations are:

1. a frame having a header and data;
2. a frame‑type indication and a security‑level indication in the header;
3. forwarding/receiving the frame; and
4. a policy that maps the frame type to a minimum security level, with the recipient accepting if the transmitted level meets the minimum and rejecting if it does not.

Everything else in the specification — the ACK‑based SEC₀ synchronization (FIGS. 7–8), the ExemptSet/OverrideSEC(m) bypass (FIGS. 12–13), the layered APL/NWK/MAC/PHY delegation (FIG. 6) — is not recited and therefore cannot supply patentable weight.

Claim-construction note. Claim 1 is drafted as a "first device" claim, but its final "wherein" clause describes the second device's acceptance logic. Under the broadest reasonable reading, claim 1 requires only that the forwarded frame be structured so that a frame‑type‑indexed minimum‑security policy applies on the receive side; the sender need not itself hold the policy. This matters: it means a sender‑side reference need only disclose frame‑type + security‑level in the header, with the policy mapping supplied by a second reference (or by admission).

Legal standard. KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007) (predictable combinations of known elements; motivation may be implicit; "if a technique has been used to improve one device, and a person of ordinary skill in the art would recognize that it would improve similar devices in the same way, using the technique is obvious"); Graham v. John Deere Co., 383 U.S. 1 (1966) (scope/content, differences, PHOSITA level, secondary considerations).

---

2. Applicant-admitted prior art (AAP) — usable without any reference

The '869 specification's own "Description of the Prior Art" states:

"There are many variations in cryptographic algorithms, and various parameters that determine the precise implementation. In standards for wireless communications, it has been customary to set these parameters in advance for each frame type. However, this approach limits the flexibility of the parameters."

This is an admission that associating security parameters with a frame type was conventional. The invention, as claimed, is essentially a relaxation of that convention (make the parameters per‑frame rather than fixed per frame type, then check the frame's security level against the frame‑type's minimum). Statements in the specification about the prior art are admissions that can be used in an obviousness analysis without any separate reference. This alone supplies much of the motivation to combine discussed below.

---

3. The material prior art of record

---

4. Grounds of rejection

Ground 1 (primary) — Struik '197 in view of Finn '431

Mapping to independent claim 1:

Every limitation of claim 1 is disclosed across these two references; the only gap in '197 is the frame‑type indication, which Finn teaches expressly. Claim 10 is the mirror image (recipient side) and is likewise met: '197's recipient extracts the security bits and compares to the minimum; Finn's device parses the frame‑type field and applies the policy.

Claim 2 (which merely recites the second device "receives the frame; determines the frame type from the header; and correlates the frame type to the policy") is met by the same combination, and adds nothing beyond claim 10's subject matter. Claim 3/11 (accept/reject) = '197 steps 128–130. Claims 6/14 (security bits the recipient extracts) = '197 "extracts the security bits at step 124," verbatim. Claims 8/16 (footer with error‑code bits) = Dunti '214's trailer with breach/fault bits, and in any event a standard frame check sequence (the '869 specification itself describes footer 176 as "one or more bits that represent an error code").

Claims 4/12 (key representation in header; policy identifies an acceptable frame type for that key) and 9/17 (key identifier + key representation + originator in header): supplied by the additional Struik references in the record — US 2004/0136527 A1 ("encoding security status information") and US 2005/0081032 A1 — and by Finn's frame‑keyed forwarding/security information, and by Dunti's per‑module security codes and identification numbers. Claim 9's "originator" is met by Dunti's per‑module identification and by '197/'032's source/destination handling.

Claims 5/13 (policy identifies frame types vulnerable to attack when certain combinations of security features are present; reject on match): Dunti '214's grant/deny logic keyed to the packet's security code, and IBM '681's policy‑profile rejection logic (a document/section is removed or a session denied when the available protection does not match the profile) supply this. Claim 5 is essentially the rationale the '869 specification gives ("a policy can cause a recipient to reject a frame for using no encryption and only authentication…") and is a routine policy‑design choice given a frame‑type‑indexed policy.

Claims 7/15 (policy implemented as a look‑up table correlating frame type to an attribute): met squarely by IBM '681 (security database/mapping table) and Finn '431 (forwarding table 200; UGPLs), and by Dunti's mapping tables.

Ground 2 — Struik '197 in view of Smith '357 (Cisco, US 2005/0097357 A1)

Substitutes the Cisco security‑labeling reference for Finn as the source of the frame‑attribute↔policy linkage. Cleaner § 102(b) status (published 2005‑05‑05), useful if one wants to avoid relying on Finn's § 102(e) date.

Ground 3 — IBM '681 in view of Finn '431

'681 supplies the "policy‑profile‑sets‑the‑minimum‑security‑level" and "table‑driven, administrable policy" teachings; Finn supplies the frame‑type field and in‑frame security information. Motivation: '681 expressly aims to apply only the security level actually required ("the application need only identify the minimum level of encryption required (or appropriate)"), which is exactly the objective served by indexing the minimum to the frame type.

Ground 4 — Dunti '214 in view of Struik '197

Dunti supplies in‑header security codes with grant/deny at the downstream module plus a breach‑indicating trailer; '197 supplies the extract‑and‑compare‑to‑minimum logic. This ground is strongest for dependent claims 8/16 but does not by itself reach the "frame type → minimum" mapping without Finn/Smith or the AAP admission.

---

5. Motivation to combine (KSR rationales)

1. The references are in the same field and address the same problem. All are link/network‑layer frame security. '197 and Finn are both addressed to protecting frame payload/overhead and enforcing a security policy on a per‑frame basis at the recipient.
2. Applicant's own admission supplies the motivation. The '869 (and '197) background expressly states it "has been customary to set these parameters in advance for each frame type." A PHOSITA seeking the claimed flexibility — per‑frame security checked against a frame‑type expectation — would naturally (i) keep the frame type in the header (already standard in Ethernet/802.11 frame control and taught by Finn FIG. 4D) and (ii) let the recipient look up the frame‑type minimum and compare it to the advertised level. That is the claimed invention.
3. Predictable result / known technique applied to a similar device. Adding a frame‑type field to a header and consulting a table is routine; the recipient already parses the header to extract the security bits ('197 step 124). KSR: "where a technique has been used to improve one device, and a person of ordinary skill in the art would recognize that it would improve similar devices in the same way, using the technique is obvious."
4. Design incentive / market pressure. '197 itself frames the problem as the inflexibility of fixed, per‑frame‑type parameters ("this approach limits the flexibility of the parameters") — i.e., the art was already thinking in terms of frame type as the parameterization unit.
5. No teaching away appears in any of the listed references; all point in the same direction (configurable, administrable, per‑frame security policy).
6. Reasonable expectation of success. Both references operate on the same frame header at the same protocol layer; combining them requires no new protocol, no interoperability risk, and no experimental uncertainty.

---

6. Anticipated rebuttals, weaknesses, and caveats

• The examiner allowed the case over this art. US 2005/0076197 A1, US 2005/0081032 A1, US 2004/0136527 A1 and the Cisco/Finn materials all appear in the '869 record, and the examiner still issued the patent. The same subject matter was also allowed in every earlier family member (US 8,688,978; US 9,667,634; US 10,097,559). That is a meaningful, though not dispositive, counterweight: the prosecution history likely shows the applicant distinguished on the frame‑type‑indexed‑minimum‑policy limitation. Any invalidity challenge should therefore be built around Finn's explicit frame‑type field (FIG. 4D) plus the applicant's own frame‑type admission, because those are the points the examiner is least likely to have addressed in combination.
• Finn's date. Because US 2006/0112431 A1 published 2006‑05‑25 (after the 2006‑04‑13 priority), it can only be relied on as pre‑AIA § 102(e) prior art, as of its 2004‑11‑23 U.S. filing date. Two consequences: (i) it must be shown to be "by another" (different inventive entity — satisfied, Finn/Smith ≠ Struik); and (ii) pre‑AIA § 103(c) could defeat a § 102(e)‑based combination if, at the time the invention was made, the '869 subject matter and Finn were commonly owned or subject to a joint research agreement. Finn is Cisco, '869 is Certicom/BlackBerry — not commonly owned — so § 103(c) should not apply; but this must be verified from assignment records. Ground 2 (substituting the Cisco Smith '357 reference, published 2005‑05‑05) avoids the § 102(e)/§ 103(c) issue entirely.
• Struik '197's § 102(b) status. It published 2005‑04‑07, i.e., more than one year before the 2006‑04‑13 priority (and a fortiori before the 2007‑04‑13 actual filing of parent 11/735,055). It is therefore a statutory‑bar reference, and the § 103(c) common‑ownership escape (which applies only to § 102(e)/(f)/(g) art) is unavailable even though the reference shares an inventor/assignee with '869. This is the single most powerful lever in a § 103 challenge, and it should be double‑checked against the certified publication date on the face of the document.
• I have not run a full claim chart for every dependent claim and have only title/abstract‑level grounding for the cumulative references (Smith '357, Han '715, Dunti's later patents, Dhawan, Kim, Sun, Itt, Canon, GI). Those should be pulled in full before being relied upon. The frames‑and‑tables above are grounded in the reference text I retrieved; the dependent‑claim groundings for claims 4/12, 5/13 and 9/17 are the least developed.
• No contradiction with earlier sections. The prior summary flagged that US 11,063,958 is a distinct, 2003‑priority family. That is consistent with what I found: US 2005/0076197 A1 is the 2003 Struik publication, and US 11,063,958 is that family's later member. Both directions of citation appear in the '869 record (the 2003 Struik publication is cited against '869; US 11,063,958 appears under Cited By). This is not an inconsistency — it reflects a family that is simultaneously prior art and a later citer.
• Secondary considerations. I found no evidence of unexpected results, long‑felt need, failure of others, or industry praise tied to the claimed subject matter, and I am not asserting any. If the patentee proffers a nexus‑bearing secondary consideration, it would have to be weighed under Graham.

---

7. Bottom line

The strongest § 103 case is: US 2005/0076197 A1 (Struik) in view of US 2006/0112431 A1 (Finn & Smith), optionally further in view of US 7,010,681 B1 (IBM) for the table‑driven policy and US 6,754,214 B1 (Dunti) for the in‑header security code and error‑code trailer. '197 discloses every limitation of claims 1/10 except the header‑borne frame type and the frame‑type‑keyed policy; Finn supplies the frame‑type field and the frame‑attribute‑keyed policy/look‑up mechanism; the applicant's own specification admits that setting security parameters per frame type was conventional. The combination is in a single field, requires no new protocol, yields a predictable result, and is not taught away. On that record, claims 1–17 would be vulnerable to an obviousness challenge, with the principal defensive hurdles being (a) the examiner's prior allowance of the same subject matter across the whole family and (b) the need to establish Finn's § 102(e) date and clean § 103(c) analysis (or to substitute Smith '357).