US 6853988

I'll search for authoritative information on US 6853988, including any 2026 CAFC activity.

Let me check for any 2026 CAFC activity and litigation/PTAB records.

I have solid bibliographic data. Now let me retrieve the actual claim text, which wasn't included in the provided excerpt.

US Patent 6,853,988 — Analyst Summary

Sourcing note / caveat: I do not have direct API access to USPTO Patent Center or the CAFC docket system. The following is grounded in public web sources (Google Patents full text, the patent PDF on patentimages.storage.googleapis.com, RPX Insight, and PTAB/USPTO assignment documents), plus the authoritative full text supplied in the prompt. Where I could not confirm something, I say so explicitly.

1. Bibliographic data (high confidence)

2. Abstract (verbatim)

"The invention is a cryptographic server providing interoperability over multiple algorithms, keys, standards, certificate types and issuers, protocols, and the like. Another aspect of the invention is to provide a secure server, or trust engine, having server-centric keys, or in other words, storing cryptographic keys on a server. The server-centric storage of keys provides for user-independent security, portability, availability, and straightforwardness, along with a wide variety of implementation possibilities."

3. Independent claims — plain-language overview

Claim 1 (verbatim text recovered via RPX Insight, so reliable):

"A method of performing remote requests for cryptographic functions on a secure server, the method comprising: associating a user from multiple users with one or more keys from a plurality of private cryptographic keys stored on a secure server; receiving a request for one or more cryptographic functions from an application executing on a remote computing device; accessing the one or more keys; and performing one or more cryptographic functions corresponding to the request using the one or more keys; wherein the step of accessing the one or more keys further comprises: selecting a type of certificate matching data provided in the request; and determining whether the user owns a certificate matching the type; when the user owns the certificate, accessing the one or more keys from the plurality of private cryptographic keys corresponding to the certificate; wherein the step of performing one or more cryptographic functions using the one or more keys includes using the one or more keys corresponding to the certificate; when the user does not own the certificate, determining whether the user owns a cross-certified-certificate cross-certified with the certificate; and when the user owns the cross-certified certificate, accessing the one or more keys from the plurality of private cryptographic keys corresponding to the cross-certified certificate."

Plain language: The user's private keys live on a secure server, never on the client. A remote application asks the server to do crypto work; the server picks the certificate type the request implies, checks whether the user already holds a matching certificate (and therefore a matching stored private key), and if so uses it. If the user doesn't hold a matching certificate, the server looks for a cross-certified certificate that the user does hold and uses the corresponding key instead. In other words: server-side key custody plus certificate-type matching and cross-certification fallback = interoperability.

Other independent claims — moderate confidence, with explicit uncertainty. The "Summary of the Invention" section of the specification enumerates the following distinct inventive aspects, each of which typically corresponds to an independent claim in this family (and each of which appears as an independent claim in the sibling publication US 2005/0102244 A1, which shares the specification):

1. A cryptographic engine (apparatus) — a cryptographic handling module that generates at least one key pair, a data splitting module that splits a key into portions, and a data assembly module that reassembles the key from at least two portions; the handling module then performs crypto functions with the reassembled key.
2. A method of managing a cryptographic system to avoid continual key reissue — generate a key pair inside a secure server, never release the private key to the user, store it server-side, and provide server-side cryptographic functionality without releasing the key.
3. A cryptographic system with a plurality of cryptographic engines — each engine receives a hash of a first file from party A and a hash of a second file from party B, compares them, and produces a comparison result; a redundancy system polls results from at least two engines to determine whether the two files were identical.
4. A method of providing interoperability between cryptographic infrastructures — store private key(s) for a user on a server; receive a request for a cryptographic action; determine the required certificate type; determine whether the user has access to a matching certificate; if yes, perform the action with the corresponding private key.
5. A second interoperability method — as above, plus: if the user lacks the matching certificate, check for a cross-certified certificate; if found, use the key corresponding to the cross-certified certificate.
6. A third interoperability method — as above, plus: if the user lacks the certificate, select a certificate authority that issues the certificate or a cross-certified equivalent, acquire it (following the enrollment steps 945–960), and perform the action with the key corresponding to the acquired certificate.

⚠️ Uncertainty flag: I could only recover the verbatim text of claim 1. Because the Google Patents page in my tool results was truncated before the claims, I cannot state with confidence (a) the exact number of claims in the patent, (b) the exact claim numbers of the independent claims listed above, or (c) their verbatim wording/full limitations. The list above is a faithful rendering of the disclosed aspects, not confirmed claim language. This should be verified against the USPTO PatentCenter "Claims" view or the granted-PDF claim column before being relied on.

4. Technical gist

The patent discloses a "trust engine" — a server-side cryptographic architecture with a transaction engine, depository(ies), authentication engine, and cryptographic engine. Its two commercially salient ideas are (i) server-centric key custody, using a data-splitting scheme (random values A and C combined with secret S via XOR, producing B and D, distributed across depositories D1–D4 so that at least two are needed to reconstruct), and (ii) transparent interoperability across differing algorithms, key types, certificate standards, and certificate authorities — including cross-certification "chaining" and on-demand acquisition of new certificates when the user's existing credentials don't fit the request. FIG. 9B is the interoperability flowchart; FIG. 8 is the data-splitting flowchart.

5. CAFC 2026 dockets and enforcement activity — nothing found for '988

• I found no CAFC 2026 docket, appeal, or opinion involving US 6,853,988. Searches for "6853988" combined with Federal Circuit / 2026 / appeal returned no results. This is consistent with the patent having expired January 20, 2022 (though past-damages appeals can outlast expiration).
• Related enforcement in the patent family's owner (Security First Innovations, LLC) that surfaced:
  • Security First Innovations, LLC v. Google LLC, 2:23-cv-00097 (E.D. Va.) — docket found on CourtListener; I could not confirm whether the '988 patent is among the asserted patents.
  • Security First Innovations, LLC v. International Business Machines Corp., 1:25-cv-00514 (E.D. Va., filed Mar. 24, 2025) — a 2025 case; PTAB exhibit lists reference U.S. Patent 8,447,695 and application 16/197,275, not the '988 patent. The case was stayed.
• ⚠️ Uncertainty flag: absence of a CAFC 2026 hit may reflect my search tooling's coverage rather than the true docket state. A definitive check requires the CAFC's PACER/CM-ECF docket or the Federal Circuit's opinions page searched by patent number.

6. Bottom line

US 6,853,988 (Dickinson et al., filed 2000-09-20, issued 2005-02-08, priority 1999-09-20, now assigned to Security First Innovations LLC, expired 2022-01-20) covers a server-centric cryptographic "trust engine" that stores split private keys on a server and resolves cryptographic requests by matching the requested certificate type against the user's certificates, cross-certified certificates, or newly acquired certificates — i.e., transparent interoperability between disparate PKI systems. Claim 1 captures the core "match the certificate type → else cross-certified certificate" logic. I found no 2026 Federal Circuit activity for this patent number, and I could not verify the complete independent-claim set — that remains the one item warranting a direct PatentCenter check.

I'll research litigation involving US Patent 6,853,988 using multiple targeted searches.

Let me refine my searches to focus strictly on patent 6,853,988 and Security First-related litigation.

Litigation Search: US Patent 6,853,988

Bottom line

Based on my searches of patent-litigation coverage (Unified Patents-style aggregators, CourtListener/RECAP, Justia, UniCourt, PTAB dockets, and CAFC-adjacent dockets), I did not find any litigation in which US 6,853,988 ("Cryptographic server with provisions for interoperability between cryptographic systems") was asserted as a patent-in-suit. I cannot confirm a single case where this specific patent was the basis of an infringement claim, and I want to be explicit that this is a negative finding rather than an exhaustive one — I was not able to fully load the Unified Patents litigation case list, so a confirmatory check there is still advisable.

Two important contextual points:

• The patent is expired. Per its Google Patents legal-status entry, US 6,853,988 is "Expired – Lifetime, expires 2022-01-20" (adjusted expiration). An expired patent cannot support prospective injunctive relief, and any damages action would be limited to pre-expiration infringement within the § 286 six-year lookback. That makes a current or recent suit asserting this patent unlikely.
• The patent's owner is a serial litigant, but on other patents. US 6,853,988 issued to Security First Corp. and its current assignee is Security First Innovations, LLC (assignment recorded 2022-08-29). Security First Innovations has been actively litigating and defending IPRs — but on later Security First patents, not the '988 patent.

⚠️ A number-collision to avoid

Search results for "the '398 patent" in Ultratec, Inc. v. Sorenson Communications, Inc. / CaptionCall, LLC, No. 3:14-cv-00066 (W.D. Wis.) concern a captioned-telephone patent — a completely different patent from US 6,853,988 (which is a cryptographic-server patent). Per your instruction not to return similar/coincidental numbers, I am flagging rather than reporting this as relevant. Likewise, a CourtListener "docket 6853988" hit (In re Anel Villarreal, 2:18-bk-15875) is merely a docket-index coincidence, not this patent.

Related Security First litigation ecosystem (these assert OTHER patents — not the '988)

Provided for context only; none of these asserted US 6,853,988 to my knowledge:

Related PTAB proceedings (all involve other Security First patents, e.g., 9,135,456; 9,338,140; 10,452,854; 11,068,609; 11,178,116):

• Google LLC v. Security First Innovations, LLC — IPR2024-00212, -00213, -00214, -00215
• IBM v. Security First Innovations / Security First Corp. — IPR2025-01202 (directed to U.S. Patent 9,135,456)

Note on a PTAB-document reference to "US-6853988"

One PTAB petition exhibit table contained the string "US-7499905-$.DID. OR US-6853988-$.DID." — this is a patent-family/document-identifier search string in a database query, not a record of litigation. Separately, another PTAB filing contains a Security First security-agreement document listing US 6,853,988 (App. No. 09/666,647, issued 02/08/2005) in an assignment/security-interest schedule. Neither constitutes an assertion of the patent in a lawsuit.

Recommendation / caveats

• Conclusion: No known litigation asserting US 6,853,988 was found. I state this as a negative finding, not a certification.
• To close the gap, the definitive sources to check directly are: the Unified Patents litigation portal (https://portal.unifiedpatents.com/litigation/caselist), PACER dockets for Security First Corp. / Security First Innovations / Enthentica (the original assignee names appearing in the chain of title), and CAFC dockets. I was unable to fully enumerate those in this session.
• If you'd like, I can run a follow-up pass keyed strictly to the exact string "6,853,988" across CourtListener/RECAP and the Unified Patents case list, and separately check the pre-2022 Security First Corp. suits (e.g., the earlier Delaware and C.D. Cal. actions against Oracle, Emulex, and others) to confirm whether the '988 patent ever appeared as a patent-in-suit.

I'll verify the canonical "no PTAB activity" signal against web sources before writing.

Let me run a few more targeted checks to be sure no proceeding on this specific patent exists (including older/reissue/reexam routes and the sibling continuations).

Proceedings overview

Total AIA trial proceedings on US 6,853,988: zero (0) — 0 active, 0 claims invalidated, 0 claims sustained, 0 settled, 0 institution denials. The USPTO Open Data Portal structured block supplied in this prompt returns no AIA trial proceedings for this patent, and my independent web passes (PTAB petition/document text on PTAB E2E, docket aggregators, Finnegan/Unified-style litigation trackers, and the SFI-v.-Google PTAB filings) turn up no IPR, PGR, CBM, or derivation proceeding ever filed against the '988. The bottom-line defensive posture: the '988 is not "hardened" by surviving IPRs — it is simply untested, and that untested status is a function of its age and expiry (adjusted expiration 2022-01-20), not of its strength. For a defendant receiving a demand letter today, the practical read is: there is no PTAB record to lean on, but there is also no live injunctive threat, and under the Office's current discretionary-denial practice a 20-plus-year-old expired patent faces steep "settled expectations" headwinds at institution. See the Feb. 2026 PTAB statistics deck (Dentons alert) and the discretionary-denial critique in the amicus brief in No. 25-1230 (describing the "settled expectations" doctrine as having been invoked "to deny hundreds of IPR petitions").

Proceedings on US 6,853,988

None to report. No proceeding number exists for this patent, and I will not manufacture one. Per the task constraint ("If no PTAB activity exists, say so plainly"), the per-proceeding template has no entries.

Why the zero is credible, not just a data gap

I checked the usual places a challenge to this patent would surface:

1. PTAB petition/document full text. Every hit on the string "6853988" in PTAB filings is not a challenge to the patent. The three recurring contexts are:
   • Security-agreement collateral schedules. Exhibit sets in the IBM petitions (IPR2025‑01110/‑01111/‑01112) reproduce an assignment/security-interest schedule listing "APPLICATION NUMBER: 09666647 FILING DATE: 09/20/2000 PATENT NUMBER: 6853988 ISSUE DATE: 02/08/2005 TITLE: CRYPTOGRAPHIC SERVER WITH PROVISIONS FOR INTEROPERABILITY BETWEEN CRYPTOGRAPHIC SYSTEMS" — i.e., the patent appears as collateral in the chain of title, not as a patent-in-suit before the Board. (example artifact)
   • A database query string. "S60 | 23 | US-7499905-$.DID. OR US-6853988-$.DID." is a document-identifier search expression in an IBM exhibit, not a proceeding record. (artifact)
   • Prior-art/results-list citations (Google Patents family and citation reports).
2. The Security First IPR cluster is entirely against other patents. Google's four 2023 petitions target the later "secure parser" family — IPR2024‑00212, ‑00213 (US 9,338,140, instituted denied), ‑00214 (US 11,068,609), ‑00215 (US 10,452,854) — and IBM's IPR2025‑01202 targets US 9,135,456. The '988 is neither challenged nor asserted in those proceedings.
3. The parallel litigation record does not implicate the '988's validity. In Security First Innovations, LLC v. Google LLC, 2:23‑cv‑00097 (E.D. Va.), the court's stay opinion notes Google's IPRs "challenge all the asserted claims across all the asserted patents in the instant case" — and the '988 is not among the patents I could tie to that case or to SFI v. IBM, 1:25‑cv‑00514 (E.D. Va.). (stay opinion; docket)

Residual uncertainty (stated explicitly)

• Reexamination is a different record from AIA trials. My sources are AIA-trial-oriented. I could not confirm whether the '988 was ever the subject of an ex parte reexamination, an inter partes reexamination (pre‑2012, available for this 2000-filed patent), or a reissue. Those would not appear in the ODP AIA-trial block. Verify directly via USPTO Patent Center → "Reexam/Reissue" documents tab, and PTAB E2E (https://e2e.uspto.gov/).
• PTAB E2E/ODP ingest lag for very recent filings is possible in principle, but given the patent expired 2022‑01‑20, a new petition is highly unlikely to be of interest to anyone.

Strategic summary

Claim status of the '988: entirely UNTESTED — no claims canceled, no claims sustained, and no substitute claims on file. Because no AIA trial was ever instituted against the '988, there is no PTAB claim-level adjudication to cite. Any statement that "claims 1–5 are canceled" or that "the patent survived two IPRs" would be false for this patent; I confirm neither occurred. All claims stand exactly as granted (subject to any reissue/reexam/erratum that I could not verify — see the gap above). The earlier summary's note that claim 1 was recovered via RPX and covers the "certificate-type match → else cross-certified certificate" logic remains the operative claim set for defensive analysis, since nothing at the Board has touched it.

Estoppel landscape: nothing is estopped, and nothing is blocked. Because there is no FWD on the '988, § 315(e)(2) estoppel does not attach, and no petitioner or privy is barred from raising any § 102/§ 103 ground. A defendant today therefore has the full universe of patents-and-printed-publications art available for an IPR — including references a hypothetical prior petitioner never used. Two practical constraints nonetheless shape the decision: (i) § 315(b) — a petition must be filed within one year of service of a complaint alleging infringement of the '988; and (ii) § 315(e)(2) is a one-way ratchet — if you institute and lose, you retain § 102/§ 103 invalidity in district court; if you institute and take an FWD, you lose it. Note also the asymmetry the E.D. Va. court flagged: after an FWD, the petitioner "cannot raise any claim that it could have raised in the IPR petition or at the IPR itself." (stay opinion) Since expiry limits exposure to pre‑2022 damages within the § 286 six-year lookback and eliminates injunctive relief, an IPR's cost-benefit case is materially weaker here than for a live patent.

Pattern signals. (1) The same petitioner has filed multiple IPRs, but only against later SFI patents — Google's four-petition volley (IPR2024‑00212/‑00213/‑00214/‑00215) is a classic coordinated multi-patent campaign, and IBM followed with IPR2025‑01202 against the '456 patent. The '988 is conspicuously absent from both. (2) The patent owner does fight at the Board — SFI files POPRs (see the IPR2024‑00213 docket, with a preliminary response and expert declarations from Rubin and Schneier; docketalarm) and, per the Patexia case summary, one Google FWD (IPR2024‑00212, FWD 2025‑05‑16, panel Giannetti/Repko/Belisle) landed in a "Pending Director Review" posture — so SFI does pursue post-FWD avenues. (3) A defensive aggregator is not the driver here on the '988: the petitions are filed by operating companies (Google, IBM), not by Unified Patents. (4) One nuance worth flagging for a defendant building an invalidity story: Google's petitions used a Dickinson-authored PCT publication (WO 2001/022322) as prior art against the Orsini-family patents — the same lead inventor as the '988. ⚠️ Uncertainty flag: I could not confirm from the sources retrieved that WO 2001/022322 is the PCT counterpart of the '988 application itself (rather than a sibling Dickinson filing); treat the identity as an inference, not a verified fact. If it is the '988's own PCT publication, it is itself citable art against later SFI patents, which cuts in a defendant's favor in the broader SFI dispute but tells you nothing about the '988's own validity.

Recommended next steps

• No PTAB disposition exists to link or quote. There is no Final Written Decision on US 6,853,988 to cite in a demand-letter response. Do not assert PTAB-based estoppel or cancellation as leverage against a demand on this patent — it would be immediately rebutted.
• Close the two open verification gaps before advising a client:
  1. AIA trials: confirm the zero on PTAB E2E (https://e2e.uspto.gov/) and USPTO Patent Center for application 09/666,647.
  2. Non-AIA proceedings: check the Patent Center documents tab for any ex parte/inter partes reexamination or reissue of the '988 (the one category this analysis could not rule out).
• Frame the defence around expiry, not PTAB. The authoritative facts to lead with: US 6,853,988 is Expired – Lifetime, adjusted expiration 2022‑01‑20; the patent issued 2005‑02‑08 from an application filed 2000‑09‑20 with priority to 1999‑09‑20. Any assertion is confined to pre-expiration damages subject to § 286; there is no injunctive exposure.
• If you nonetheless contemplate an IPR (e.g., to defeat a pre-2022 damages theory or to blunt a stare-decisis effect in a broader SFI campaign), calendar the § 315(b) one-year-from-service date first, and brief the discretionary-denial risk up front — a patent this old and already expired is the paradigm case for the Office's current "settled expectations" reluctance to institute, per the Feb. 2026 PTAB statistics and the Supreme Court amicus challenge in No. 25‑1230.
• For context in the wider SFI dispute (not the '988): the live, decision-relevant AIA matters are Google's IPR2024‑00212 (FWD 2025‑05‑16, pending Director Review), the denied IPR2024‑00213, IPR2024‑00214, IPR2024‑00215, and IBM's IPR2025‑01202. Watch those if your exposure involves the later SFI "secure parser" patents, but do not conflate them with the '988.

I'll research the assignment chain for US 6,853,988, starting with the USPTO Assignment Center and cross-referencing the legal events in the authoritative patent text.

Let me dig deeper into the specific assignment records, reel/frame numbers, and correspondents.

Good progress on reel/frame numbers. Let me pin down the earliest recordings and correspondents.

I hit my tool-step limit while retrieving the individual correspondence fields and the two earliest reel/frame numbers. Below is everything I could ground, with the gaps flagged explicitly rather than filled with guesses. No assignments are fabricated — every entry below traces to the Google Patents legal-events block in the authoritative patent text supplied in the prompt and/or a corroborating recording I actually retrieved.

Inventors

Pattern note (material): All five inventors assigned to Ethentica, Inc. on 2001-03-26 — i.e., ~6 months after the 2000-09-20 filing — and the entire portfolio (this patent plus the WO 01/022322, 01/022319, 01/022201, 01/022651, 01/022650 siblings, all priority 1999-09-20) moved together. The company's own record confirms Ethentica, Inc. was formerly "Who? Vision Systems, Inc." (the recording is styled "ETHENTICA, INC. F.K.A. WHO? VISION SYSTEMS, INC."). A five-inventor simultaneous assignment, followed by a sale to a private-equity firm (below), is the classic signature of a corporate asset transfer / portfolio sale after the dot-com crash, not of individual inventor assignment. ⚠️ I could not confirm whether the inventors left Ethentica within 12 months — that requires personnel records I did not retrieve.

Original assignee

• Entity named on the issued patent (2005-02-08): Security First Corp (Google Patents face data).
• Nuance / apparent inconsistency to flag: the application chain shows the inventors assigning to Ethentica, Inc. (2001-03-26), and the WO counterpart lists the original/parent assignee as Ethentica, Inc. Security First Corp appears as assignee-of-record only because it acquired the patents from Topspin Partners in Dec. 2004, i.e., before the Feb. 2005 issue date. So "original assignee = Security First Corp" on the face reflects the owner at issuance, not the developer. This reconciles the earlier-generated summary's "Original Assignee Security First Corp" entry with the 2001 Ethentica assignment.
• Primary line of business: Security First Corp. (Rancho Santa Margarita, CA — confirmed address in the 2016 security agreement: "29811 Santa Margarita Parkway, Suite 600, Rancho Santa Margarita, CA 92688") is a data-security/software company built around the patented "trust engine" and later the "secure data parser" family. Ethentica/Who? Vision was a fingerprint-biometric sensor and authentication company.
• Status: Security First Corp. is the operating/parent entity; the patent was ultimately moved to its licensing arm Security First Innovations, LLC (Virginia) in 2022. Whether Security First Corp. remains an operating entity in 2026, or is itself dissolved, I could not confirm in this session. ⚠️ I found no confirmed Chapter 7/11 filing for Ethentica or Security First — see signal 6.

Assignment timeline

Chronological; every entry grounded in the authoritative Google Patents legal-events list, with reel/frame added where I retrieved it. Read the confidence tag on each reel/frame.

• 2001-03-26 (recorded) — Reel not retrieved ⚠️

  • Conveyance: Assignment of assignors' interest
  • Assignor: Dickinson, Alexander G.; Rohrbach, Mark D.; Clayton, Richard F.; Ferrante, Michelle; Stark, Gregory H. (the five inventors)
  • Assignee: Ethentica, Inc. (California)
  • Correspondent: not retrieved ⚠️ (the prosecuting firm is Knobbe, Martens, Olson & Bear — see next entry)
  • Context: Founder/inventor-to-company assignment — the developers conveyed the application to their employer.

• 2001-04-25 (recorded) — Reel not retrieved ⚠️

  • Conveyance: Security interest (Security Agreement)
  • Assignor: Ethentica, Inc.
  • Assignee: Knobbe, Martens, Olson & Bear, LLP (California — the law firm)
  • Correspondent: not retrieved ⚠️
  • Context: Securitization — the company granted its outside patent counsel a security interest in the patents (a fee-collateral arrangement). This is an operating-company trigger, not an NPE tell — but it recurs (2014).

• 2004-12-20 (recorded; executed 2002-02-07 per the sibling record) — Reel 015477/0275 ✅

  • Conveyance: Assignment of assignors' interest
  • Assignor: Ethentica, Inc. f/k/a Who? Vision Systems, Inc.
  • Assignee: Topspin Partners, LP (New York)
  • Correspondent: not retrieved ⚠️
  • Context: Sale / fire-sale to a financial buyer — the operating biometric company sold its patent portfolio to a private-equity/VC firm (Topspin Partners is a Long Island PE/VC). Note the ~2.4-year gap between execution (2002-02) and recording (2004-12) — a distressed-transfer signature.

• 2004-12-23 (recorded; executed 2004-02-22 per the sibling record) — Reel 015495/0931 ✅

  • Conveyance: Assignment of assignors' interest
  • Assignor: Topspin Partners, LP
  • Assignee: Security First Corporation
  • Correspondent: not retrieved ⚠️
  • Context: Transfer to operating acquirer — Topspin flipped the portfolio to Security First Corp., which then took the patent to issuance (issue date 2005-02-08).

• 2014-09-30 (recorded; effective date 2003-01-31 per the Google event) — Reel 033868/0244 ✅

  • Conveyance: Release by secured party
  • Assignor: Knobbe, Martens, Olson & Bear, LLP
  • Assignee: Ethentica, Inc.
  • Correspondent: filed by the Knobbe firm itself as secured party (its recording, adjacent to the next)
  • Context: Security-interest release — clean-up of the 2001 law-firm lien.

• 2014-09-30 (recorded) — Reel 033868/0450 ✅

  • Conveyance: Security interest termination
  • Assignor: Knobbe, Martens, Olson & Bear, LLP
  • Assignee: Ethentica, Inc.
  • Correspondent: same firm, same reel 033868, adjacent frames (/0244 and /0450) — repeat-recorder tell (see signal 3)
  • Context: Security-interest termination — belt-and-suspenders paired with the release above.

• 2016-06-24 (recorded; effective 2016-04-12) — Reel 039153/0321 ✅

  • Conveyance: Patent Security Agreement
  • Assignor: Security First Corp. (grantor)
  • Assignee: LG Management LLC; Topspin SFC Holdings LLC; O'Reilly, David; Jordan, Gerald R. Jr.; Granprix Limited; LTE Partners; Wu, Jasper; and ~40 more named individuals/entities (a large lender/investor syndicate)
  • Correspondent: not retrieved ⚠️
  • Context: Securitization — Security First Corp. pledged the entire patent portfolio (this patent listed by "APPLICATION NUMBER 09666647 … PATENT NUMBER 6853988") to a syndicate of investors as collateral. Topspin SFC Holdings LLC is the successor to the 2004 buyer — the same financial backer staying in the chain.

• 2022-08-29 (recorded; effective 2022-08-04) — Reel 061262/0865 ✅ (this is the key link)

  • Conveyance: Assignment of assignors' interest
  • Assignor: Security First Corp.
  • Assignee: Security First Innovations, LLC (Virginia)
  • Correspondent: SFI's counsel of record on the sibling '116 prosecution is Farjami & Farjami LLP, 26522 La Alameda Ave, Mission Viejo, CA — ⚠️ treat as probable recording correspondent, not confirmed for this specific reel
  • Context: Transfer to licensing/assertion arm. ⚠️ Critical: the same reel/frame 061262/0865 is cited in the 2023 prosecution history of US 11,178,116 as the instrument by which that patent (and by implication the whole portfolio) moved from Security First Corp. to Security First Innovations, LLC. One reel/frame covering multiple patents = a bulk, portfolio-wide assignment. Also note: this transfer is dated after the patent's 2022-01-20 expiry.

• 2022-09-30 (recorded; effective date shown as 2020-10-16 in the Google event — internally inconsistent, flag) — Reel 061578/0505 ✅

  • Conveyance: Release by secured party
  • Assignor: Altmann, Eric; Auber Investments Ltd.; Barle, Stanko; Barton, Wesley W.; … Gyenes, Andy; Simons, Barbara; and others (the 2016 secured syndicate)
  • Assignee: Security First Corp.
  • Correspondent: not retrieved ⚠️
  • Context: Securitization release — the 2016 lender syndicate released its collateral lien, clearing title after the August 2022 assignment to SFI LLC. The ordering (assign to SFI LLC 2022-08, then release 2022-09) means SFI LLC took subject to the syndicate's lien until the release was recorded.

⚠️ Verification gaps (stated plainly): I did not retrieve (a) the reel/frame for the 2001-03-26 Ethentica assignment or the 2001-04-25 Knobbe security interest, nor (b) the correspondent-of-record fields for any recording. Those three data points must be pulled directly from the Assignment Center. The three public "list every recording" sources never agreed on the 2001 reel numbers and I would not guess them.

Verification link: USPTO Assignment Center — search patent 6,853,988 (indexed at assignment.uspto.gov).

Timeline diagram

timeline
    title Ownership of US 6853988
    2000 : Application filed 20 Sep 2000
    2001 : Inventors assign to Ethentica Inc
         : Ethentica grants lien to Knobbe Martens
    2002 : Ethentica sells portfolio to Topspin Partners
    2004 : Topspin assigns patent to Security First Corp
    2005 : Patent issues 08 Feb 2005
    2014 : Knobbe Martens lien released
    2016 : Security First pledges portfolio to lender group
    2022 : Patent expires 20 Jan 2022
         : Assigned to Security First Innovations LLC
         : Lender group releases lien

NPE / troll-pattern signals

1. Shell-entity transfer — PRESENT (qualified). The patent moved from operating assignees (Ethentica → Security First Corp.) to Security First Innovations, LLC, a Virginia LLC, per Reel 061262/0865 (recorded 2022-08-29). SFI LLC's conduct (it holds no product line and has sued Google and IBM) establishes it as a licensing-only entity. However, this transfer is dated after the '988's 2022-01-20 expiry, so the classic "transfer arranged to enable assertion of this patent" inference is weakened for the '988 specifically (it was never asserted — see the litigation section).

2. Known asserter in the chain — PRESENT. Security First Innovations, LLC is a documented high-frequency plaintiff: SFI v. Google LLC, 2:23-cv-00097 (E.D. Va., 2023) and SFI v. IBM Corp., 1:25-cv-00514 (E.D. Va., 2025). It does not appear on the classic NPE lists in the prompt (Acacia, Marathon, IV, etc.), so this is an asserter-by-conduct finding, grounded in filed complaints, not a name-list match. ⚠️ Those suits assert later SFI patents, not the '988.

3. Repeat correspondent across the chain — PARTIAL / UNCLEAR. I could not retrieve the correspondent-of-record fields, so I cannot certify a repeat attorney. What I can ground is a repeat recorder of a different kind: Knobbe, Martens, Olson & Bear, LLP appears twice as the filing party — as security-interest holder in 2001 and as the releaser on Reel 033868/0244 and Reel 033868/0450, both recorded 2014-09-30 on the same reel, adjacent frames. Separately, reel 039153/0321 (2016) and reel 061262/0865 (2022) are each bulk instruments covering a whole portfolio, indicating a single coordinated recorder per transaction. This is suggestive, not conclusive. Mark: unclear — requires the Assignment Center correspondent fields.

4. Cascading transfers — PRESENT. Chain includes Ethentica → Topspin Partners (executed 2002-02-07, recorded 2004-12-20, Reel 015477/0275) immediately followed by Topspin → Security First Corp. (executed 2004-02-22, recorded 2004-12-23, Reel 015495/0931) — two hops within days on the recording side, through a financial intermediary (Topspin). Then a decade later Security First Corp. → SFI LLC (Reel 061262/0865, 2022) within months of expiry. Chained transfers through a PE vehicle are present and documented.

5. Pre-litigation transfer — UNCLEAR / NOT ESTABLISHED for this patent. SFI LLC took the '988 on 2022-08-29 (Reel 061262/0865) and was litigating by 2023 — a ~12-month gap to litigation generally, which fits the "arranged to assert" window. But the '988 is expired and, per the litigation section, was never the patent-in-suit. So the transfer-for-assertion tell applies to the portfolio, not to this patent. Mark unclear.

6. Bankruptcy fire-sale — UNCLEAR. The Ethentica → Topspin Partners transfer (executed 2002-02-07, Reel 015477/0275) has the shape of a distressed asset sale (dot-com-era biometric company, ~2.4-year execution-to-recording lag, sale to a PE firm), but I found no confirmed Chapter 7/11 filing for Ethentica/Who? Vision or Security First Corps. I will not infer bankruptcy from the transfer shape alone. Mark unclear.

7. Privateering — NOT PRESENT / UNCLEAR. No SEC filing or press coverage surfaced showing an operating company funding SFI LLC's suits against its own competitors. The Security First Corp. → SFI LLC move (Reel 061262/0865) is an internal-name licensing carve-out rather than a classic third-party privateering arrangement. Mark not present on the retrieved record.

8. Defensive aggregator (anti-NPE) — NOT PRESENT. The chain terminates at Security First Innovations, LLC (Reel 061262/0865) — an asserter, not RPX/AST/LOT/Unified/OIN. No defensive-aggregator link exists.

Verdict

NPE — moderate confidence.

Justification (citing reel/frame + dates): The chain terminates at Security First Innovations, LLC, a documented licensing-only litigant, via a portfolio-wide assignment recorded at Reel 061262/0865 (effective 2022-08-04, recorded 2022-08-29) — a transfer to an asserter entity, which is one strong signal; it is reinforced by the cascading Topspin-intermediated transfers (Reel 015477/0275 → Reel 015495/0931, both recorded Dec. 2004). That said, this verdict describes the assignee entity, not an active threat on this patent: the '988 expired 2022-01-20 before the SFI LLC transfer, was never asserted in the SFI v. Google / SFI v. IBM matters, and has no PTAB record — so any NPE posture here is historical only, with pre-2022 damages the sole residual exposure.

Verification: USPTO Assignment Center — patent 6,853,988 and Google Patents legal events.

Two cross-section reconciliation notes

1. No contradiction with the litigation or PTAB sections: SFI LLC's assertions (Google 2023, IBM 2025) involve later patents, and the '988's assignment is post-expiry — consistent with the "expired, untested, unasserted" findings there.
2. One flagged internal inconsistency in the primary record itself: the final release (Reel 061578/0505) shows a 2020-10-16 effective date in the Google legal-events data yet was recorded 2022-09-30, after the 2022-08-29 assignment to SFI LLC. Either the effective-date field is mis-indexed or the release post-dates the assignment — worth confirming on the Assignment Center document PDF, as it affects whether SFI LLC's title was ever subject to the 2016 syndicate lien.

I'll research the prior art cited on the face of US 6,853,988, plus examiner-cited references. Let me run several targeted searches.

The Google Patents excerpt isn't surfacing the citation tables. Let me try other sources that tabulate the patent's cited references.

I have the "Cited By" data but not the "References Cited" section. Let me retrieve the front page of the granted PDF, which lists the examiner-cited references.

A note on what I could and could not retrieve

I hit my tool-step limit mid-research, so I want to be transparent about a gap rather than paper over it.

What I confirmed: the bibliographic record, the abstract, the specification, claim 1 verbatim, the family, and the forward citation list ("Cited By (148)").

What I could NOT retrieve: the front-page "References Cited" / "Patent Citations" (backward) list for US 6,853,988. That list — the examiner-cited U.S. patent documents, foreign documents, and NPL — is exactly what your task asks me to enumerate reference-by-reference with dates and § 102 mappings. I could not pull that table: every retrieval returned the specification's "Definitions" section, the family table, or the forward-citation table, and my final targeted retrievals for the front-page citation table were cut off by the step limit.

Per my operating rules, I will not fabricate a citation list and attach § 102 conclusions to it. Inventing "References Cited" entries with confident dates would be exactly the kind of error you can't detect but which would poison an invalidity analysis. So the reference-by-reference table you asked for is not deliverable in this session — and I'm flagging that up front rather than burying it. Below is everything I can ground, plus a rigorously-labeled best-effort framework.

B. A critical framing point: "Cited By" ≠ prior art

The one citation table I did fully retrieve is the forward citation list (148 entries), which is not § 102 prior art for the '988 patent. Almost all of those documents post-date the '988 priority date (1999-09-20) or even its filing date (2000-09-20). Examples I directly observed:

⚠️ If a future analyst pulls the Google Patents "cited by" panel and treats it as the prior-art set, they will invert the analysis. The relevant list is the backward one (front page "References Cited," typically ~15–40 entries for a 2005-issued, 1999-priority software patent).

I also observed that the sibling publication US 20030229705A1 lists "Patent Citations (28)" and that EP2568406B1 / EP1908210A4 cite '988 — again, forward-direction only.

C. References I can ground from the authoritative patent text itself

These are internal/incorporated references mentioned in the '988 specification (not necessarily front-page citations, but real and citable):

1. U.S. patent application Ser. No. 08/926,277, filed Sep. [1997] — referenced at col. describing the biometric device 107. The spec states the biometric device "may advantageously comprise a device having attributes and features similar to those disclosed in U.S. patent application Ser. No. 08/926,277, filed on Sep. …". Use: relevant to the biometric-authentication limitations (biometric capture/enrollment data), i.e., the authentication-engine aspects, not the certificate-interoperability core of claim 1.

   • ⚠️ Full filing day was truncated in my source; verify.

2. Provisional applications claimed as priority (from the earlier-generated section, treated as authoritative): 60/154,734, filed 1999-09-20 and 60/200,396, filed 2000-04-27. These are the patent's own priority chain, not prior art.

3. Copyright/standards references named in the spec as the state of the art it improves upon: the SSL Protocol (v2/v3) (spec: "1/2 SSL" and "FULL SSL"); PKCS10 (certificate request) and PKCS7 (certificate format); PGP (Pretty Good Privacy), RSA, ELGAMAL; LDAP; HTML/XML; and named CAs (VeriSign, Baltimore, Entrust). These are the fields in which examiner prior art would sit, but the spec does not cite them as claim-anticipating references.

D. Best-effort prior-art classes most relevant to the claims — flagged as framework, not verified citations

Because I could not pull the actual cited list, treat the following as my analytical framework for what the references most likely are and how they'd map, indexed to the claim limitations. Each item is a class, with example references only where I have high confidence the reference exists and is in the right field. Every specific number below must be verified against the granted front page before use.

Independent claim 1 (core: server-side private keys + certificate-type match + cross-certified fallback)

My assessment: the cross-certification fallback in claim 1 is the limitation with the thinnest pre-1999 prior art, because cross-certification across CAs was an emerging concept in the 1999 window. The server-centric key custody limitations have substantial prior art (key escrow, key recovery, roaming credentials) — so if any § 102 rejection was made, it most plausibly attacked the server-storage elements, with the interoperability elements carrying the patentability.

Independent claims covering the data-splitting / trust-engine apparatus

Independent claims covering multi-engine hash comparison + redundancy

E. § 102 mapping — stated conservatively

Because I cannot confirm the actual cited references, I will not assert specific "Reference X anticipates claim N" conclusions. What I can state with confidence is the analytic shape:

• Data-splitting claims (the A/B/C/D 2-of-4 scheme): most vulnerable under § 102 to pre-1999 secret-sharing/IDA references (Shamir/Blakley/Rabin lineage), since the mathematical construction is equivalent to a two-of-four information-dispersal scheme. If front-page art includes such a reference, expect it cited against these claims.
• Server-centric key-storage claims: vulnerable under § 102 to key-escrow/key-recovery art.
• Interoperability claims (claim 1 and the three interoperability methods): least vulnerable; the cross-certified-certificate fallback is the differentiator. Expect these to have survived on that limitation.
• Redundancy/hash-comparison claims: vulnerable to generic voting/redundancy art.

F. Caveats and the specific verification steps to close this

1. Do not treat the "Cited By (148)" list as prior art — those are forward citations and post-date the priority/filing dates (verified examples in § B).
2. The one deliverable you asked for that I owe you is the front-page references-cited table. To obtain it definitively:
   • USPTO Patent Center → application 09/666,647 → "Documents & Transactions" → the issued patent PDF front page (columns "References Cited"), or
   • patentimages.storage.googleapis.com granted-PDF for US 6,853,988, page 1 ("U.S. PATENT DOCUMENTS", "FOREIGN PATENT DOCUMENTS", "OTHER PUBLICATIONS"), or
   • Global Dossier / Espacenet "Cited documents" tab for the '988 family.
3. Cross-check the sibling patents US 7,577,621 and US 8,494,969 (same spec/same title, continuations) — their front pages frequently carry the same prior-art list as '988, and one of them may have a cleaner examiner citation set.
4. Contradiction flag for the earlier sections: the previously-generated summary cited provisional 60/200,396 (filed 2000-04-27) and 60/154,734 (1999-09-20), but the authoritative Google Patents page in my prompt lists the priority date simply as 1999-09-20 and gives no provisional numbers in the visible metadata. I could not independently verify those provisional numbers in this session; treat them as needing confirmation, not settled fact.
5. I found no PTAB or litigation record in which '988 itself was invalidated, so there is no public IPR decision that already crystallized the winning prior-art combination for these claims — the mapping above is my analytical inference only.

If you can supply the granted front page or the Patent Center "References Cited" export, I can complete the reference-by-reference table with full citations, dates, descriptions, and precise § 102 claim mappings in a single pass.

I'll research the prior art landscape for US 6,853,988, focusing on the references cited on its face and in its family, plus contemporaneous art in server-side cryptography, key custody, certificate interoperability, and data splitting.

Let me drill into the specific prior-art references cited on the face of the patent and the surrounding art.

Let me try to retrieve the exact "References Cited" list from the patent and check the family's key prior art.

Before the analysis, an important sourcing caveat.

⚠️ Premise / sourcing limitation (must read before relying on this)

You asked me to "use the results from the Prior Art section of this page." The page text supplied to me is truncated before the claims and before the "References Cited" / citation-column portion. The excerpt ends mid‑sentence in the FIG. 13 discussion. Consequently:

• I do not have the patent's own face-level "References Cited" list (the examiner-cited U.S. patent documents, foreign documents, and NPL).
• The only "prior art" data the supplied text actually gives me is the Google Patents "Prior art keywords" field — authentication; data; user; engine; cryptographic — plus the background definitions section.
• My web tooling for this session was cut off before I could load the patent's citation table. I therefore cannot attest that any specific reference below was cited by the examiner in the '988 prosecution.

So the grounds below are constructed from (i) the claim scope established in the family summary, (ii) references that appear in the citation tables of sibling/descendant Security First patents (which share the '988 specification), and (iii) well-established contemporaneous literature in the field. Every ground should be re-verified against the actual "References Cited" column and the file wrapper before being used in a validity opinion. I flag confidence per item.

Obviousness analysis — US 6,853,988 under 35 U.S.C. § 103

1. Legal framework and effective date

• Priority date: September 20, 1999 (provisional 60/154,734), filing September 20, 2000. Prior art must therefore qualify under §102(a)/(b)/(e) as of that date; the second provisional (60/200,396, Apr. 27, 2000) is after the priority date and does not affect the §102 window for the challenged claims.
• Law: Graham v. John Deere (scope/content of claims; differences over prior art; PHOSITA level; secondary considerations), and KSR Int'l v. Teleflex, 550 U.S. 398 (2007) (motivation may be supplied by design incentives, market forces, and a finite number of predictable solutions; a combination need not be taught by the references themselves).

2. Claim scope (as established)

Recovered verbatim claim 1 is the workhorse interoperability claim. Its limitations, decomposed:

The unclaimed "surroundings" — data splitting (A, C random values; B = A XOR S, D = C XOR S; distributed to D1–D4 so at least two are needed), multiple geographically separated depositories, parallel authentication, attempt limiting, redundancy polling, trust arbitrage — are largely described but not required by claim 1. That matters: for §103 purposes, the breadth of claim 1 is captured by server-side key custody + certificate-type matching + cross-certification fallback.

Critical caveat (carried from the family summary): I have verbatim text only for claim 1. The number of claims, the exact language of the other independent claims (the cryptographic-engine apparatus, the anti-reissue method, the multi-engine redundancy system, and the two other interoperability methods), and their full limitations are unverified. The grounds below are keyed primarily to claim 1 and to the disclosed aspects; they must be re-mapped to actual claim language.

3. Person of ordinary skill in the art (POSITA)

At the 1999 priority date, a POSITA would be an engineer/scientist with a bachelor's degree in CS/EE (or equivalent) plus 2–4 years of experience in applied cryptography and PKI, familiar with: RSA/DSA public-key cryptosystems; X.509 v3 certificates; PKCS#7/#10; secret sharing; and networked (Web/SSL) application design. This level is high enough that X.509 cross-certification, key escrow, and server-side signing were all routine knowledge, not research frontiers.

4. The prior-art reference set

Confidence noted per group.

Group A — Server-side / third-party custody of private keys (key escrow & recovery). High confidence these existed and were well known.

• Micali's "Fair Public-Key Cryptosystems" (CRYPTO '92, LNCS, pp. 113–138, 1993) and the Micali patent family (e.g., U.S. 5,615,269; 5,629,982; 5,638,447; 5,666,414; 5,666,416; 5,677,955; 5,717,757–5,717,759; RE35,808) — teach a user's private key held/split by fiduciaries/trustees and reconstructed only with corroboration. (These numbers appear in the citation tables of Security First's own later U.S. 7,337,315 — not confirmed as cited on the '988 face.)
• Kilian & Leighton, "Failsafe Key Escrow," CRYPTO '95; Leighton, "Failsafe Key Escrow Systems," MIT/LCS TM-458 (1994) — split-key escrow with redundancy.
• Lenstra, Winkler & Yacobi, "A key escrow system with warrant bounds," CRYPTO '95 — escrow with policy constraints on release.
• Bellare & Rivest, "Translucent cryptography — an alternative to key escrow," MIT/LCS TM-683 (Feb. 1996); Ellison, Hall, Milbert & Schneier, "Protecting secret keys with personal entropy," Future Generation Comp. Sys. 16(4):311–318 (2000) (and earlier USENIX work).
• Commercial key-recovery/CA systems: Entrust, Baltimore, VeriSign OnSite — third-party key custody and signing services.

Group B — Server/agent performing cryptographic operations on a user's behalf. High confidence.

• Proxy signatures — Mambo, Usuda & Okamoto, "Proxy Signatures: Delegation of the Power to Sign Messages," IEICE Trans. Fundamentals (1996); "Proxy Signatures for Delegating Signing Operation," ACM CCS 1996 — a designated server signs on behalf of a principal.
• US 5,659,616 (Sudia) and the Sudia notarization/delegation line — centralized digital-signature/notary services (appears in the cited-art tables of Security First descendants).
• US 5,745,738 (Bisbee et al.) — secure server-mediated transaction system.

Group C — Certificate interoperability, cross-certification, chaining, CPS. Very high confidence.

• RFC 2459, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile" (Housley, Ford, Polk, Solo, Jan. 1999) — expressly describes cross-certification and name constraints.
• X.509 v3 (ITU-T, 1997) and the SET specification's CA cross-certification model (1997).
• Federal Bridge CA / Federal PKI architecture (Burr, NIST, 1998) — cross-certification and policy mapping between CAs.
• Certificate policy/CPS-based trust-level mapping ("chaining") — the very concept recited in FIG. 9B's description.
• Microsoft CryptoAPI (CAPI) and PKCS#11 — certificate/key selection by intended use / key attributes from a local or network key store.

Group D — Threshold secret sharing & information dispersal (for the apparatus/anti-reissue aspects). Very high confidence.

• Shamir, "How to Share a Secret," CACM 22(11):612–613 (1979); Blakley (1979).
• Rabin, "Efficient Dispersal of Information for Security, Load Balancing, and Fault Tolerance," JACM 36(2):335–348 (1989) and the related Rabin IDA patents — the D1–D4 dispersal scheme is a direct application.
• Micali fair cryptosystems (Group A) also disclose splitting a private key across trustees.

Group E — Biometric authentication in a networked cryptographic system. High confidence.

• The '988 specification itself cross-references U.S. application Ser. No. 08/926,277 (biometric capture device) and the sibling Ser. No. 09/666,377 (US 7,260,724, "Context sensitive dynamic authentication"), filed the same day — relevant to the authentication aspects, not claim 1.

5. Grounds of rejection

Ground 1 — Claim 1 obvious over Micali (fair cryptosystems / key escrow) in view of RFC 2459 (X.509 cross-certification)

Mapping.

• 1a–1d (server-stored private keys; remote request; access; perform): Micali discloses a user's private key held in escrow by fiduciaries and released/reconstructed to enable cryptographic operations; commercially, CA/key-recovery servers (Group A) performed this centrally.
• 1e–1g (select certificate type from request; determine user owns matching certificate; use its key): RFC 2459 / X.509 v3 and CAPI/PKCS#11 make certificate selection by intended use/type a routine step; a server holding the user's certificates can trivially test ownership.
• 1h–1i (cross-certified fallback): RFC 2459's cross-certification / policy mapping and the Federal Bridge CA teach exactly that a user holding certificate X can satisfy a request for certificate type Y when X is cross-certified to Y.

Motivation. Both references attack the same problem — how a relying party decides to trust, and how keys are made available to, an entity whose credentials do not match the relying party's native format. X.509 cross-certification was, by 1999, the canonical answer to "different PKI islands don't interoperate." A POSITA charged with making a key-custody server usable across many CAs/standards would have had a strong, specific reason to add a cross-certified fallback to a request-matching routine; the combination yields nothing more than the predictable sum of its parts. KSR rationale (C)/(F): known technique (cross-certification) applied to a known device (key server) ready for improvement, responsive to obvious market demand for PKI interoperability.

Ground 2 — Claim 1 obvious over a server-side digital-signature / proxy-signature system (Mambo et al.; Sudia) in view of RFC 2459

Mapping. Proxy-signature schemes and centralized notarization systems disclose a server that receives a signing/crypto request and performs it with a key not released to the client — 1a–1d. The server must choose which of the principal's keys to use; PKI certification practice requires selection by the certificate type/usage the relying party demands (1e–1g). Where the principal's certificates aren't of the demanded type, X.509 cross-certification supplies the substitute (1h–1i).

Motivation. A server holding multiple keys per user (a necessary consequence of Group A/D key sets) must have a rule for choosing among them; "match what the requester asked for, else use a cross-certified equivalent" is the natural, and by 1999 conventional, rule. KSR rationale (A): combination of prior-art elements by known methods to yield predictable results.

Ground 3 — (Apparatus / anti-reissue aspects) obvious over Shamir/Blakley (secret sharing) or Rabin (IDA) in view of Micali (escrowed split key)

For the disclosed cryptographic-engine and anti-reissue aspects (split key stored across depositories; reassemble only with ≥2 portions; never release private key), Shamir's threshold scheme and Rabin's IDA supply the splitting/reassembly mechanism (A, B, C, D XOR constructions are the standard XOR-sharing variant), and Micali's fair cryptosystems supply the "split the private key among fiduciaries so it is never wholly exposed" application. Motivation: fault tolerance + no single point of compromise — expressly the stated design goals in the '988 specification, and the stated goals of the references themselves. Expectation of success: high; XOR/threshold sharing is deterministic arithmetic.

Ground 4 — (Redundancy aspect) obvious over key-escrow/redundancy art + distributed comparing engines

For the disclosed plural cryptographic engines plus a redundancy module polling ≥2 comparison results, Micali/Leighton failsafe-escrow redundancy and Byzantine-fault-tolerant agreement (e.g., Feldman & Micali, "Optimal algorithms for Byzantine agreement," STOC 1988) supply "poll multiple, require a quorum." Motivation: reliability and resistance to a single compromised node.

Ground 5 — (Interoperability methods 4–6; CA selection/acquisition) obvious over RFC 2459 + commercial CA enrollment practice

The "select a CA that issues the needed certificate or a cross-certified equivalent, then acquire it (per enrollment steps 945–960)" aspect is the ordinary CA enrollment/certificate-request workflow (PKCS#10 → PKCS#7), combined with cross-certification. Motivation: obvious to try — when the user lacks the needed credential, obtain one; a finite, predictable set of CA choices.

6. Anticipation (§102) vs. obviousness note

For claim 1 as a whole, I did not locate (in the sources actually retrieved) a single reference disclosing all of: key-server custody + certificate-type selection from the request + cross-certification fallback. That is why I frame the combining grounds under §103 rather than §102. This is not a clearance of claim 1 — it is a statement that the retrieved art supports a §103 combination, and that a full §102 search keyed to the actual cited-art list was not completed.

7. Secondary considerations (objective indicia)

Nothing in the retrieved record evidences: unexpected results, long-felt-but-unsolved need, industry praise, copying, or commercial success attributable to claim 1's specific ordering of steps. The interoperability "fallback-to-cross-certified" ordering is an expected application of X.509 policy mapping, i.e., a predictable result of combining known elements — the KSR posture where nexus to a nonobvious advance is absent.

8. Conclusion and confidence

Recommendation: before any opinion is issued, obtain (a) the granted-PDF claims column, and (b) the USPTO Patent Center "References Cited"/file-wrapper list, then re-run Grounds 1–5 mapped to the actual claim language. The combination framework above should survive, but the specific references must be swapped for whatever the examiner actually cited (and any applicant-submitted IDS art), so the motivation statements can be tied to TSM language in those references.

I did not fabricate a citation list for this patent; the limitation above is real, not boilerplate.