US 6978369

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

Let me check for any CAFC 2026 docket or litigation activity specifically involving this patent.

US Patent 6,978,369 — Analyst Summary

Caveat on sourcing: The authoritative full text I was given is the Google Patents rendering of US6978369B2. My supplementary searches returned Google Patents, Justia, Patexia, uspto.report, and Unified Patents records. I did not obtain a live PatentCenter/Patent Public Search record directly, and — importantly — my searches returned no CAFC 2026 docket, no IPR/PGR, and no litigation activity for patent number 6978369. I will state that plainly rather than infer appellate activity that I cannot verify.

Bibliographic data

Abstract (verbatim)

"In a method of managing a database of existing accounts (214) for account holders (202), each account holder (202) has multiple accounts with one or more account authorities (212) for use of a single device with multiple accounts, with each account of each account holder being associated with a public key of a public-private key pair of that account holder. A record of information pertaining to all accounts of a particular account holder is maintained in a central location by a central key authority. The information for that account includes the public keys of that account holder. The central key authority transfers information from the record for an account holder to a new account authority for which that account holder desires to establish a new account; the central key authority also receives information from account authorities for inclusion in the record centrally maintained for that account holder."

Note the mismatch worth flagging: the abstract emphasizes the "Central Key Authority" aspect (the specification's third aspect), whereas claim 1 is directed to the person-centric multi-account aspect (the second aspect).

Plain-language overview of the independent claims

The patent has two independent claims: claim 1 (method) and claim 81 (device). Claims 2–80 depend from claim 1; claims 82–91 depend from claim 81. (The printed text contains drafting anomalies I am reporting literally: claim 84 reads "The method of claim 81…" and claim 88 reads "The method claim or 81…" — these appear in the granted text as reproduced.)

Claim 1 — Method of communicating electronically about accounts (person-centric, multi-account core).
For a first account: (a) keep account information in a database retrievable by a first unique identifier; (b) associate a public key of a public/private key pair with that identifier; (c) generate a digital signature over an electronic message using the private key, where the message contains an instruction and the first unique identifier; (d) authenticate the message using the public key associated with the information identified by the first unique identifier; and (e) on successful authentication, execute the instruction against the first account.
For a second account: repeat the same five steps, but — critically — associate the same public key (the one already associated with the first account) with the second unique identifier. In plain terms: one device/one key pair signs account-specific messages, and each account authority (or record) looks up the same public key via its own identifier, then acts on the instruction.

Claim 81 — Device used in electronic communication about an account.
A device that includes (a) a private key of a public/private key pair, and (b) a plurality of unique account identifiers, each identifying an account maintained by an account authority with which the public key of that same key pair is associated. In plain terms: the claimed article is a personal signing device that holds one private key plus a stored list of the several account identifiers that have been bound to its public key. (Dependent claims 82–83 add that the device carries or can derive the identity of each account authority so the signed message can be routed to the correct authority.)

Notable dependent-claim scope (for context only)

The dependent set is broad on implementation: external vs. in-device message composition and hashing (19–23), contact/swipe/contactless/wireless/RF interfaces (24–28), execution "based solely on successful authentication" (29), and a long list of instruction types — balances, debits, credits, funds transfers, database/physical-location/data-transmission access, goods, services, payments, securities, charges, information transfer (30–43). The device-form claims span PCs, cell phones, PDAs, electronic keys, dongles, subcutaneous implants, secure chips, jewelry, IC/credit/debit/security cards, and ID badges (59–71), plus "no personally-identifying information" and unencrypted-message limitations (75–78).

On the requested USPTO / CAFC 2026 docket check

• CAFC 2026 dockets for 6978369: none found. Targeted queries for the number against Federal Circuit/2026 appeal activity returned no results. I cannot confirm any 2026 appellate proceeding, and I am not aware of one with high confidence.
• USPTO: The record shows only prosecution history and security-interest reassignments (Credit Suisse 2007; Wells Fargo 2010/2011; terminations/releases 2019) — no post-grant trial (IPR/PGR) or reexamination for this patent surfaced in my searches.
• The patent is expired, which is consistent with why no current enforcement or appellate activity appears.

Because I could not query the CAFC's own docket system or PatentCenter directly, the absence of results should be read as "no evidence found," not as proof that no such proceeding exists.

I'll research litigation involving US patent 6978369 across patent litigation databases.

The initial results are about different patents (6,957,369; 7,177,369; 11,967,369) — not US 6,978,369. Let me search more specifically for the patent in question and its inventors/owner.

Let me search patent litigation databases and PTAB for this specific patent.

I'll start by verifying the structured data against public sources.

Let me probe for any AIA trial filings and related litigation activity.

Let me try a few more angles — CBM reviews, litigation history, and docket databases.

Proceedings overview

Zero (0) AIA trial proceedings on file for US 6,978,369. The structured PTAB block for this patent — sourced from the USPTO Open Data Portal — returns no AIA trial proceedings, and my independent web searches (IPR, PGR, and CBM angles, plus PTAB E2E / aggregator portals) surfaced no IPR, PGR, or CBM petition or institution for this patent number. Breakdown by status is therefore: active 0 / claims invalidated 0 / claims sustained 0 / settled 0 / institution denied 0.

The bottom-line defensive posture this gives a defendant is unusual and, frankly, weak for the challenger: the patent has never been stress-tested at the PTAB, so there is no cancelled-claim shortcut and no petitioner estoppel to exploit — but the reason is almost certainly commercial, not legal. The patent expired on 2021-11-28 (Google Patents legal status: "Expired – Lifetime, expires 2021-11-28"), so by the time AIA trials matured into a routine defense tool, the asserted value of this particular member of the Wheeler/First Data family was winding down. You get no free invalid claims, but you also inherit a very large, untouched prior-art universe and no § 315(e)(2) estoppel record to work around.

Confidence note / caveat: I was unable to complete every search I wanted (tool-step limit) and I did not have direct PTAB E2E or Docket Navigator access. The absence of proceedings is my best-supported finding from the ODP structured data plus multiple web searches, not a certified negative. Before relying on it, have counsel run a native PTAB E2E / Docket Navigator party-and-patent query. Treat "no PTAB activity on file" as the working assumption, per the task framing.

Proceedings

None. There are no proceeding numbers to report, and I will not invent any. Because the requested per-proceeding block (petitioner, panel, grounds, institution decision, FWD, settlement, appeal) presupposes a filed petition, that section is intentionally empty rather than padded with speculation.

For completeness on what I did find in the surrounding docket space — none of which is an AIA trial against 6,978,369:

• CardSoft (Assignment for the Benefit of Creditors), LLC v. First Data Corp., First Data Merchant Services Corp., and TASQ Technology, Inc., No. 2:13-cv-00290 (E.D. Tex.) — First Data was a defendant here, on U.S. Patent 6,934,945 (CardSoft's patent), not an assertion of 6,978,369. (RPX Insight litigation record; CourtListener docket 4530730).
• DataTreasury Corp. v. Wells Fargo & Co. et al., No. 2:06-cv-00072 (E.D. Tex.) — First Data appeared as counsel/party in the check-processing patent litigation; again, unrelated to the '369 patent.
• First Data acquired this Wheeler family through assignment (recorded 2001-08-06 to First Data Corp.) rather than asserting it in the NPE suits above. I found no district court complaint asserting 6,978,369, and correspondingly no litigation-triggered IPR.

Strategic summary

Claim status: everything is UNTESTED. All 91 claims issued with this patent remain as granted — claim 1 (the two-account method claim) and claim 81 (the device claim) were never adjudicated at the Board. Confirm the current claim set against the USPTO PatentCenter file wrapper, but there is no PTAB certificate cancelling anything. Contrast that with the typical "hardened" narrative: a patent that has survived two IPRs is narrowed but validated; this patent is neither narrowed nor validated — it is simply unexamined by the Board. That is a materially different posture. You cannot point a judge at a Federal Circuit affirmance of validity, but neither can the patent owner point at an FWD sustaining claim 1.

Estoppel landscape: none exists, and that cuts in the defendant's favor. § 315(e)(2) estoppel attaches only to a petitioner that obtained a final written decision. With no FWDs, no party is estopped, and no prior-art ground has been "used up." Any Section 102/103 ground you want to run in district court — or in a fresh IPR — is available. Two practical bounds worth flagging: (i) this is a pre-AIA patent (effective filing 2001-08-06, priority 2000-08-04), so PGR is unavailable (§ 321 applies only to first-inventor-to-file patents) and CBM is off the table — the CBM window closed to new petitions on 2020-09-16, and the patent's own expiry forecloses any lingering CBM revival; and (ii) an IPR can technically still be filed against an expired patent (see Sony Corp. v. Iancu, 924 F.3d 1235 (Fed. Cir. 2019)), but claims of an expired patent are construed under Phillips rather than the broadest reasonable interpretation, and the patent owner can moot the fight by disclaiming claims it no longer intends to assert.

Pattern signals. No repeat petitioner (there is no petitioner). No patent-owner appeal activity at the Federal Circuit on this patent number. No defensive aggregator — I found no Unified Patents proceeding or RPX-initiated challenge tied to 6,978,369; Unified's portal surfaces the patent only as citation/family data, not as a challenged proceeding. The decisive pattern signal here is the expiry date: the patent lapsed on 2021-11-28, which is a far better explanation for the empty PTAB docket than any implied validity strength. Note also that the '369 patent is one node in a large Wheeler portfolio (siblings include US 6,820,202; US 6,915,430; US 6,938,156; US 6,950,940; US 6,957,336; US 7,016,691; US 7,143,284; US 7,200,749; US 7,552,333, among others). If a licensing campaign is live in this family, the effort is more likely to rest on a non-expired sibling than on this patent — and the PTAB history of those siblings is a separate, and more fruitful, query.

Recommended next steps

If you are a defendant facing an assertion of 6,978,369 today, the first question is damages, not validity. The patent expired 2021-11-28. Under 35 U.S.C. § 286, recovery reaches back only six years before suit; absent tolling, an assertion filed late in 2026 could at most capture infringement from roughly late 2020 to the November 2021 expiry — a window of about a year, and one that is shrinking toward zero. Push hard on the damages cutoff and on laches-adjacent notice issues before spending anything on prior art.

On validity, you are unconstrained. With no PTAB record, every ground is open, and you can attack in district court under Phillips framing without dancing around an FWD. Because no IPR was filed, there is no § 315(b) clock running against you and no estoppel to manage — you may file an IPR, though I'd weigh whether the cost is worth it for an expired patent when a district court invalidity case (or simply the damages cutoff) may be the cheaper kill.

Statutory-outcome check you should still run yourself. Confirm there is genuinely nothing in PTAB E2E and Docket Navigator — a dedicated "patent number 6,978,369 + all party names (Wheeler, First Data Corp., First Data Merchant Services, TASQ)" query, since aggregator coverage of pre-2013 reexaminations and early CBM filings is spotty. If that query also comes back empty, the correct and defensible statement to a court or an adversary is the blunt one: there is no PTAB activity on this patent — the absence is itself a signal that the patent was never valuable enough, or long-lived enough, to attract an AIA challenge.

If you are the patent owner / licensor: the absence of any PTAB proceeding is mildly favorable optics, but you should not characterize the patent as "survived IPR challenges" — that would be affirmatively false. And because the patent is expired, any demand letter resting on 6,978,369 is exposed to a threshold attack on recoverable damages; a live sibling in the Wheeler family is the stronger vehicle.

I'll start by pulling the assignment/ownership record from the sources available to me, then cross-check.

Let me dig for the specific assignment reel/frame records and any post-First Data transfers.

Assignment & Ownership Analysis — US 6,978,369 B2

Patent: Person-centric account-based digital signature system
Appl. No.: 10/343,678 (371(c)(1),(2),(4) date 2003‑02‑03) · PCT: PCT/US01/41587, filed 2001‑08‑06 · WO 02/13455 pub. 2002‑02‑14 · Provisional: 60/223,076 filed 2000‑08‑04
Issued: 2005‑12‑20 · 91 claims · Terminal disclaimer filed · Adjusted expiration: 2021‑11‑28 · Status: Expired – Lifetime

Data-limitation notice (read first). The USPTO Assignment Center / Patent Assignment Search presents each record with a reel/frame, a correspondent of record, and an execution date. I was able to confirm the existence, type, parties and recordation dates of every post‑issuance filing through the Google Patents legal‑events feed, the PlainSite USPTO‑assignment mirror for appl. 10/343,678, and uspto.report. I could not retrieve the reel/frame numbers, the execution dates, or the correspondent of record for any entry. The PlainSite docket page for this application displays the Reel/Frame and Parties columns but returned empty values for every row. I will not invent reel/frame or attorney names. Where a field is missing below it is marked not retrieved.

Inventors

Basis for the employer call: an assignment of assignors' interest from both named inventors to First Data Corporation (Greenwood Village, CO) was recorded on 2001‑08‑06, the same day the PCT application was filed. The inventors' listed residence city in the later‑filed sibling patents is Greenwood Village, CO, which is First Data's headquarters city. That combination (simultaneous filing + assignment, inventor residence = assignee HQ) is the standard signature of employee inventors under a pre‑existing obligation to assign.

Unusual patterns (note these; they are not NPE signals):

• A two‑person, same‑surname, same‑residence inventor pair (a wife/husband pair on their face) rather than an engineering team. The portfolio is effectively a two‑person authorship family spanning 18+ US patents (see family list below), all against a single corporate assignee.
• Self‑publication before filing. The specification's own "Other References" list cites the Account Authority Digital Signature Model web page at garlic.com/~lynn/aadsover.htm and garlic.com/~lynn/aadswp.htm — the "~lynn" user directory matches the inventor's first name, i.e. the inventors' own pre‑filing published architecture is cited inside their own patent.
• No inventor departure is visible in the record. There is no assignment out of the inventors to any party other than First Data, and no later re‑assignment back to either inventor.
• The family appears in Unified Patents' portal under "Parent Company: Fiserv Inc" (e.g. US 2003/0097561 A1, US 2002/0129248 A1), which is the correct ultimate‑parent answer post‑2019 and is not evidence of an inventor‑side transfer.

Original assignee

First Data Corporation, Greenwood Village, Colorado.

• Line of business: payment processing — merchant acquiring, card‑issuer processing, STAR/PIN‑debit network, Western Union (then a unit), TeleCheck, CardService International, TASQ, Linkpoint, FundsXpress. A large, revenue‑generating operating company, not a holding vehicle.
• Did it ship a product embodying the claims? Not established on the record I retrieved. The patent is written as an architecture/standards specification, not a product spec. Its own citation list shows the assignee's commercial context as a 2001 NACHA pilot for ATM‑card payments over the Internet and a collaboration with the X9.59 "Account‑Based Secure Payment Objects" draft standard ("Digital Signatures Can Secure ATM Card Payments on the Internet, NACHA Pilot Concludes," Jul. 23, 2001; "X9.59 Working Draft," Sep. 25, 1998). Those are standards/pilot activities, not proof that First Data shipped a commercial system practicing claim 1. I therefore mark this unclear, and note that any such finding should not be inferred from the assignee's general size.
• Current status: operating, but no longer independent. First Data was taken private in the KKR-led buyout that closed in 2007, relisted as NYSE: FDC in 2015, and was acquired by Fiserv, Inc. in a merger that closed 2019‑07‑29. First Data now operates as a Fiserv subsidiary; Fiserv, Inc. is the ultimate parent. Google Patents still lists "First Data Corp" as both original and current assignee of record, which is consistent with no recorded conveyance of title.
• Patent status: expired 2021‑11‑28 (adjusted), subject to a terminal disclaimer. Any assertion value has lapsed.

Assignment timeline

Every record below is a recordation event; the Google Patents legal‑events feed does not expose execution dates. Reel/frame and correspondent are not retrieved for all rows (see data‑limitation notice).

2001‑08‑06 (recorded) — Reel not retrieved

• Conveyance: Assignment — "Assignment of Assignors' Interest (see document for details)"
• Assignor: Lynn Henry Wheeler; Anne M. Wheeler (individuals)
• Assignee: First Data Corporation, Greenwood Village, CO
• Correspondent: not retrieved. (Note: the prosecution attorney of record printed on this patent and its siblings is Morris, Manning & Martin, LLP, Atlanta, GA — this is the patent's printed agent firm, not confirmed as the assignment correspondent. I flag it only because it recurs on at least three family patents (US 6,851,054; US 7,143,284; US 7,200,749); it is not evidence of anything NPE‑related.)
• Context: initial title vesting — inventor‑to‑employer assignment executed concurrently with the PCT filing.

2007‑10‑31 (recorded) — Reel not retrieved

• Conveyance: Security Agreement
• Assignor: CardService International, Inc.; DW Holdings, Inc.; First Data Corporation; First Data Resources, Inc.; FundsXpress, Inc.; Intelligent Results, Inc.; Linkpoint International, Inc.; Size Technologies, Inc.; TASQ Technology, Inc.; TeleCheck International, Inc.; TeleCheck Services, Inc.
• Assignee: Credit Suisse, Cayman Islands Branch, as Collateral Agent
• Correspondent: not retrieved
• Context: corporate securitization/financing lien — a portfolio‑wide grant of a security interest across the First Data subsidiary group (consistent with the 2007 KKR buyout financing), not a transfer of title.

2010‑11‑17 (recorded) — Reel not retrieved

• Conveyance: Security Agreement
• Assignor: DW Holdings, Inc.; First Data Resources, Inc. (k/n/a First Data Resources, LLC); FundsXpress Financial Networks, Inc.; Intelligent Results, Inc. (k/n/a First Data Solutions, Inc.); Linkpoint International, Inc.; Money Network Financial, LLC; Size Technologies, Inc.; TASQ Technology, Inc.; TeleCheck International, Inc.
• Assignee: Wells Fargo Bank, National Association, as Collateral Agent
• Correspondent: not retrieved
• Context: refinancing lien — replacement collateral grant to a new collateral agent.

2011‑01‑31 (recorded) — Reel not retrieved

• Conveyance: Security Agreement
• Assignor: same subsidiary group as the 2010‑11‑17 record (Wells Fargo release line 2019‑08‑19 mirrors this list)
• Assignee: Wells Fargo Bank, National Association, as Collateral Agent
• Correspondent: not retrieved
• Context: refinancing lien (second, corrected/expanded filing) — note this is the second Wells Fargo collateral grant inside ~10 weeks. This pair would trip a keyword‑based "cascading transfer" filter, but both are liens, not conveyances.
• Flag: same assignee (Wells Fargo, as Collateral Agent) and near‑identical assignor group as the previous row — a recurring collateral agent, not a recurring NPE attorney.

2019‑07‑30 (recorded) — Reel not retrieved

• Conveyance: Release by Secured Party (see document for details)
• Assignor: Credit Suisse AG, Cayman Islands Branch (successor to the 2007 collateral agent)
• Beneficiaries: First Data Resources, LLC; TASQ Technology, Inc.; TeleCheck Services, Inc.; Size Technologies, Inc.; CardService International, Inc.; First Data Corporation; TeleCheck International, Inc.; FundsXpress, Inc.; Linkpoint International, Inc.; DW Holdings, Inc.; Intelligent Results, Inc.
• Correspondent: not retrieved
• Context: lien release — release of the 2007 Credit Suisse collateral package.

2019‑08‑19 (recorded) — Reel not retrieved — record 1 of 3

• Conveyance: Termination and Release of Security Interest in Patent Rights
• Assignor: Wells Fargo Bank, National Association
• Beneficiaries: First Data Corporation; DW Holdings, Inc.; First Data Resources, Inc. (k/n/a First Data Resources, LLC); Intelligent Results, Inc. (k/n/a First Data Solutions, Inc.); Size Technologies, Inc.; TeleCheck International, Inc.; FundsXpress Financial Networks, Inc.; Money Network Financial, LLC; TASQ Technology, Inc.; Linkpoint International, Inc.
• Correspondent: not retrieved
• Context: lien release on debt repayment, coinciding with the Fiserv merger closing (2019‑07‑29).

2019‑08‑19 (recorded) — Reel not retrieved — record 2 of 3

• Conveyance: Termination and Release of Security Interest in Patent Rights
• Assignor: Wells Fargo Bank, National Association
• Beneficiaries: Money Network Financial, LLC; Size Technologies, Inc.; First Data Solutions, Inc.; FundsXpress Financial Network, Inc.; First Data Corporation; TeleCheck International, Inc.; DW Holdings, Inc.; Linkpoint International, Inc.; First Data Resources, LLC; TASQ Technology, Inc.
• Correspondent: not retrieved
• Context: lien release (duplicate filing across subsidiary sets) — same event, different assignor groupings.

2019‑08‑19 (recorded) — Reel not retrieved — record 3 of 3

• Conveyance: Termination and Release of Security Interest in Patent Rights
• Assignor: Wells Fargo Bank, National Association
• Beneficiary: First Data Corporation
• Correspondent: not retrieved
• Context: lien release (First Data Corporation‑specific record).

What is absent from the record: there is no recorded assignment of this patent away from the First Data/Fiserv corporate family. No LLC named "…IP," "…Patents," "…Licensing," "…Holdings" or "…Ventures" ever takes title. No record to Acacia, Marathon, Intellectual Ventures, IPNav, Wi‑LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, or any Spangenberg entity. No record terminating at RPX, AST, LOT Network, Unified Patents or OIN.

Timeline diagram

timeline
    title Ownership of US 6978369
    2000 : Provisional filed by the Wheelers
    2001 : PCT filed
         : Inventors assign rights to First Data
    2003 : US national stage entered
    2005 : Patent issued
    2007 : Security agreement to Credit Suisse
    2010 : Security agreement to Wells Fargo
    2011 : Second security agreement to Wells Fargo
    2019 : Credit Suisse lien released
         : Wells Fargo liens released
         : First Data acquired by Fiserv
    2021 : Patent expired

(No parentheses, slashes, commas or other parser‑breaking punctuation in the event text. The 2019 Fiserv line is parent‑company context, not an assignment of this patent.)

NPE / troll-pattern signals

1. Shell‑entity transfer — NOT PRESENT.
No post‑issuance conveyance of title to any LLC appears in the record. The only LLCs in the chain — First Data Resources, LLC, Money Network Financial, LLC, and the First Data Solutions, Inc. name change — appear exclusively as release beneficiaries on the 2019‑07‑30 and 2019‑08‑19 lien terminations, i.e. as First Data operating subsidiaries, not as single‑purpose acquisition vehicles. No registered‑agent address, no single‑member Delaware/Texas LLC acquiring title.

2. Known asserter in the chain — NOT PRESENT.
Neither the 2001‑08‑06 assignee (First Data Corporation) nor any party in the 2007‑10‑31 through 2019‑08‑19 records (Credit Suisse, Cayman Islands Branch; Wells Fargo Bank, N.A., as Collateral Agent) matches any entity on the Acacia / Marathon / IV / IPNav / Wi‑LAN / Conversant / Vringo / Pendrell / Innovatio / MPHJ / Lumen View / Round Rock / Document Generation Corp lists. Secured lenders taking a portfolio‑wide collateral interest are not asserters.
Caveat: I was unable to complete a live cross‑check against RPX Insurance and Unified Patents high‑frequency‑plaintiff directories before my research budget was exhausted; the finding is based on the recorded chain itself.

3. Repeat correspondent across the chain — UNCLEAR / NOT DETERMINABLE.
The correspondent of record field is not retrievable for any of the eight filings (see data‑limitation notice). What I can say precisely: the printed prosecution agent on this patent and at least three siblings is Morris, Manning & Martin, LLP (Atlanta, GA) — a firm with heavy operating‑company patent practice. That is a single‑firm recurrence on the face of the patents, not a recurring assignment correspondent, and a single appearance (even a repeated prosecution appearance) is expressly not the signal you asked me to test for. No finding. I decline to attribute any assignment filing to that firm.

4. Cascading transfers — NOT PRESENT.
Zero ownership transfers after the initial inventor→First Data assignment, therefore no chained LLC cascade. The closest thing in date‑proximity is the 2010‑11‑17 / 2011‑01‑31 pair of Wells Fargo security agreements (~10 weeks apart, same collateral agent, overlapping assignor lists). Both are liens on the same corporate group, not conveyances, and the "recurring party" is a bank acting as collateral agent — the opposite of the NPE tell.

5. Pre‑litigation transfer — NOT PRESENT.
No infringement suit naming this patent surfaced in my searches, and there is no assignment in the 6 months preceding any litigation date. The 2019 filings are releases, dated after the Fiserv merger closing (2019‑07‑29), i.e. housekeeping, not venue‑shopping.

6. Bankruptcy fire‑sale — NOT PRESENT.
First Data never filed Chapter 7/11. Its 2007 take‑private (KKR) and 2019 sale (Fiserv) were equity transactions; the 2019 records are voluntary lien terminations on debt repayment, the inverse of a §363 sale. There is no "…→ Oracle/Nortel/Kodak‑style" sale of this patent.

7. Privateering — NOT PRESENT.
No operating company → NPE transfer, and no SEC‑filing or Patent Progress/EFF‑style coverage linking this patent to a proxy assertion campaign surfaced.

8. Defensive aggregator (anti‑NPE) — NOT PRESENT.
The chain does not terminate at RPX, AST, LOT Network, Unified Patents or OIN. The patent sits where it started, inside the original corporate family, and has simply expired.

Verdict

Insufficient data

Justification. The recorded chain after the initial 2001‑08‑06 inventor→First Data Corporation assignment consists entirely of security agreements and their releases — Credit Suisse, Cayman Islands Branch as Collateral Agent (recorded 2007‑10‑31), Wells Fargo Bank, N.A. as Collateral Agent (recorded 2010‑11‑17 and 2011‑01‑31), and the corresponding Credit Suisse release (2019‑07‑30) and three Wells Fargo terminations (2019‑08‑19). Not one of these conveys title, none names an NPE, and the assignee of record remains First Data Corporation (now a Fiserv, Inc. subsidiary since the 2019‑07‑29 merger). With the patent expired 2021‑11‑28 under a terminal disclaimer, the assertion‑value question is moot regardless.

I stop at "insufficient data" rather than "defensive/non‑asserting" because the chain terminates in an operating acquirer's corporate family, not at a defensive aggregator; and rather than "operating‑company assertion" because I found no suit and could not verify that First Data shipped a product practicing claim 1. Two caveats you should carry forward: (a) every reel/frame, execution date and correspondent field is missing from my source data and must be pulled directly from the Assignment Center; (b) a full RPX/Unified asserter cross‑check was not completed, so signals 2 and 3 are unproven rather than affirmatively negative.

Verify here: https://assignmentcenter.uspto.gov/ — search patent number 6978369 (or appl. 10/343,678); the same underlying records are indexed at https://assignment.uspto.gov/patent/index.html. Cross‑references used: Google Patents legal events for US 6,978,369 B2; PlainSite USPTO docket for appl. 10/343,678; uspto.report/patent/grant/6978369; Unified Patents portal family entries.

Family list (for portfolio‑wide correspondent / assignee cross‑checking)

All share the 2000‑08‑04 priority and the Wheeler inventor pair, and all list First Data Corporation as assignee: US 6,820,202 · US 6,820,199 · US 6,851,054 · US 6,915,430 · US 6,952,773 · US 6,957,336 · US 6,959,381 · US 6,978,369 · US 6,983,368 · US 6,981,154 · US 7,010,691 · US 7,028,185 · US 7,047,416 · US 7,143,284 · US 7,200,749 · US 7,257,228 · US 7,519,821 · US 7,549,050 · US 7,784,106 · US 7,941,664 · US 8,620,814.

I'll research US patent 6978369 and its cited prior art references.

I have the full citation list. Let me verify titles/dates for the most likely-relevant references.

Prior‑Art Analysis — US 6,978,369 B2

1. Patent identified (literal, as requested)

Source: https://patents.google.com/patent/US6978369/en and https://uspto.report/patent/grant/6978369

Claim scope that matters for §102. Independent claim 1 is the "two‑account / one key" method: for a first account — store account info retrievable by a first unique identifier, associate a public key with that identifier, generate a digital signature over a message containing an instruction and the first unique identifier using the private key, authenticate using the retrieved public key, execute the instruction; and then for a second account, repeat all of the above "associating the same public key that is associated with the first account with the second unique identifier." Independent claim 81 is the mirror‑image apparatus claim: a device containing a private key and a plurality of unique account identifiers, each identifying an account maintained by an account authority with which the public key is associated. Nearly all remaining claims (2–80, 82–91) are dependent fall‑backs (business types, device form factors, encryption/no‑encryption, no‑PII messages, etc.).

2. Methodology and explicit limitations

• The complete front‑page citation list was retrieved from two independent reproductions of the USPTO record (Justia and uspto.report), which agree, and cross‑checked against the Google Patents page. I did not independently open all ~140 cited documents; where I state a reference's subject matter, I have flagged whether it was verified by search or is title/listing-derived and unverified.
• I did not auto‑correct any identifier. Where the record itself is internally inconsistent (e.g., CA 2271178 is listed as "May 1999" on Justia and "July 1999" on uspto.report), I report the discrepancy rather than picking one.
• A genuine §102 anticipation requires every element of a claim in one reference. On the face of it, almost nothing in this citation list anticipates claim 1, because the "same public key bound to two different account identifiers" limitation is the point of novelty and is rarely disclosed. The list is therefore best read as (a) an obviousness ( §103) bank, and (b) art against the many dependent claims. I say so explicitly below rather than over‑claiming §102 hits.
• Note also the date gate: any cited reference whose effective US filing/publication date falls after 2000‑08‑04 cannot be §102(a)/(b) art; it could only matter under pre‑AIA §102(e) (and only if by another and filed before the applicant's invention date). Several listed items — e.g., 6,282,522 (Aug. 28, 2001), 6,314,519 (Nov. 6, 2001), 6,324,525 (Nov. 27, 2001), 6,373,950 (Apr. 16, 2002), 6,510,516 (Jan. 21, 2003), 6,523,067, 6,532,451, 6,565,000, 6,571,339, 6,587,837, 6,594,633, 6,671,805, and US 2002/0120846 — issue after the priority date and are presumptively not §102(a)/(b) art.

Also note: US 6,978,369 appears in the forward citation lists of later patents (e.g., US 9,054,860), and US 7,047,416 ("Account-based digital signature (ABDS) system"), US 7,127,606 ("Trusted authentication digital signature (TADS) system") and US 2002/0026575 are same‑family/sibling Wheeler filings, not prior art (co‑pending, same inventive entity) — relevant only to double‑patenting, not §102.

3. Tier 1 — Most relevant prior art

3.1 The inventor's own "Account Authority Digital Signature" materials (the most dangerous art)

These are cited in the patent as "Other References," which means the Examiner and the applicants both placed them on the record. Because the priority date is 2000‑08‑04, anything published more than one year before that date is §102(b) art even if authored by the inventor.

1. "Account Authority Digital Signature Model" web page, http://www.garlic.com/~lynn/aadsover.htm, "believed available at website after Nov. 8, 1997," captured 2001‑10‑02, 5 pp. — Verified as listed; content not opened.
   • Relevance: This is the AADS concept itself — signing to an account (account authority holds the key‑to‑account binding) instead of to a certificate. If it discloses storing a signer's public key against an account record and authenticating an instruction with it, it reads on claim 1(a)(i)–(v) and claims 44–46, 79–80.
   • Potential §102: Claim 1 (first‑account half), 44, 79, 80. Anticipation of the second‑account half requires the page to disclose one key for multiple accounts — I could not verify that it does.
2. Stewart, D., "Account Authority Digital Signatures: Enabling Secure Internet Transactions via Existing Payment Processes & Infrastructure," www.garlic.com/~lynn/aadswp.htm — listed, not opened. Same analysis.
3. "X9.59 Working Draft," ABA, ANS X9.59‑199X, For the Financial Services Industry: Account‑Based Secure Payment Objects, pp. 1–26, Sep. 25, 1998. — listed, not opened. This is the ANSI standard for account‑based signed payment objects and is squarely §102(b) art against claim 1 and its payment‑oriented dependents (claims 29–43).
4. Arthur, D., "AADS Option for Buyer Authentication; Response to NACHA/IC ANT 2 RFI," pp. 1–3, Sep. 14, 1998; NACHA pilot press items (Jul. 23, 2001; Feb. 23, 2003); Kutler, "Privacy Broker: Likely Internet Role for Banks?" (Oct. 8, 1998); Hettinga and Denny, Journal of Internet Banking and Commerce (Mar. 31, 1999). — Same §102(b) window; relevant to claims 1, 73–78 (open/insecure medium, no PII in message).

3.2 Public key bound to an account/identity rather than to a certificate

1. US 5,659,616 — Sudia, "Method for securely using digital signatures in a commercial cryptographic system," Aug. 19, 1997 (title verified in the record's own listing schema; content not opened). — Adds/uses a public key in a commercial signature system without a full PKI chain; relevant to claims 1, 44, 46, 79.
2. US 6,009,177 — Sudia, "Enhanced cryptographic system and method with key escrow feature," Dec. 28, 1999. — Key‑management/association; claim 44–46, 79–80.
3. US 5,903,882 — Asay et al., "Trusted infrastructure support systems, methods and techniques for secure electronic commerce, electronic transactions, commerce process control and automation, distributed computing, and rights management," May 11, 1999. — Broad trusted‑transaction infrastructure; relevant to claims 1, 2–4 (account authority / database maintenance) and 34–43 (access granting, payment, transfers).
4. US 5,677,955 — Doggett et al., "Electronic funds transfer instruments," Oct. 14, 1997. — Electronic "check"/payment instrument authenticated to a bank account; most relevant to claims 1, 31–33, 39–42.
5. US 6,029,150 — Kravitz, "System and method for performing an electronic financial transaction," Feb. 22, 2000. — Account‑backed electronic payment authorization; claims 1, 31–33, 39–42, 48–49.
6. US 5,790,677 — Fox et al., "System and method for secure electronic commerce transactions," Aug. 4, 1998. — Claims 1, 12–18 (intermediate party/merchant flows), 39–42.
7. US 5,883,810 (Mar. 16, 1999) and US 6,000,832 (Dec. 14, 1999) — Franklin et al. — Electronic purchase over a network; claims 1, 12–18, 37–39.
8. US 5,590,197 — Chen et al., "Electronic payment system and method," Dec. 31, 1996 (title and abstract verified by search). — Verified: the "cyber wallet" is expressly described as "an expansion of the credit card concept into a concept involving multiple cards with multiple issuers in a convenient package," with a public‑key file whose keys are selected by identifier, and the wallet may live on a smart card or PDA.
   • Why it matters: This is the closest cited art on the multi‑account, single holder device idea that claim 81 and the second half of claim 1 capitalize on — but the cyber wallet's cryptography is encryption to the servicer's private key, not digital signature by the holder's private key. So it does not anticipate claim 1 or 81. It is, however, strong §103 material against the "one device ↔ many accounts" concept, and directly relevant to claims 81–91.

3.3 Device‑centric / device‑profile art (claims 57–58, 81–91)

1. US 5,781,723 — Yee et al., "System and method for self‑identifying a portable information device to a computing unit," Jul. 14, 1998 (title and content verified by search). — Verified: the portable device carries a device class tag and registration/security attributes; a certifying authority accesses manufacturer records correlating device types and security attributes with the mathematical complements of the class tags, and issues a certificate that "might also include a security level."
   • Relevance: This is the closest cited art to the patent's Device Profile / Security Profile and "security characteristics of a device" features. Potential §102: claims 57–58 (account information regarding the device, including security characteristics), and claims 44–46 read with 57–58. Not claim 1.
2. US 6,102,287 — Matyas, Jr., Aug. 15, 2000 — listed; title not independently verified. Flagged as a candidate for the "plurality of keys / one device" limitation of claim 82a-style embodiments; I do not assert content.
3. US 5,778,072 — Samar, "System and method to transparently integrate private key operations from a smart card with host‑based encryption services," Jul. 7, 1998 (title and content verified by search). — Verified: private key never leaves the smart card; a key‑store manager holds a database describing "for each user … the encryption scheme they are using." Relevant to claims 5, 8–11, 24–28, 65, 67–72 (device holds private key; device interface; card/dongle).

3.4 Electronic‑money / token art

1. US 5,557,518 (Sep. 17, 1996), US 5,453,601 (Sep. 26, 1995), US 5,745,886 (Apr. 28, 1998), US 5,963,648 (Oct. 5, 1999) — Rosen (trusted agents / electronic monetary system). — Claims 1, 30–33, 39–42.
2. US 6,205,437 — Gifford (Mar. 20, 2001) and US 5,724,424 — Gifford (Mar. 3, 1998) — claims 34–38 (granting access to content/transmissions).
3. US 6,134,325 — Vanstone et al., Oct. 17, 2000 — key‑agreement/implicit‑signature art; candidates for claims 44–47. Content not verified.
4. US 4,868,877 (Sep. 26, 1989) and US 5,422,953 (Jun. 6, 1995) — Fischer — public‑key signature certification / signature collection. Foundational; relevant to claims 1, 44, 79.

3.5 Smart‑card / IC‑card payment art

1. US 6,282,522 — "Internet payment system using smart card" (Aug. 28, 2001) and US 6,314,519 (Nov. 6, 2001) — Davis et al. — Date‑gated: issued after 2000‑08‑04; only §102(e) possible and only if filed earlier. Relevant at most to claims 24, 65, 67–70 (IC/credit/debit card devices).
2. US 5,539,828 / 5,796,840 / 5,949,881 / 5,970,147 — Davis — smart‑card secured communications and cryptographic device registration; claims 24–28, 65–72.
3. US 5,940,? / 5,913,? — not present; not substituted.

4. Tier 2 — Complete remaining U.S. citations (number · date · inventor · most‑relevant claims)

Dates and inventors below are transcribed from the record's front‑page citation list. Titles are not given where I did not verify them — I will not fabricate them.

Foreign patent documents: CA 2271178, listed as "May 1999" on the Justia reproduction and "July 1999" on the uspto.report reproduction (discrepancy reported literally; not resolved). Only one foreign document was cited.

5. Non‑patent literature (verbatim from the record, grouped by likely weight)

The full NPL list is very long; the highest‑weight items for §102 purposes are:

• X9.59 Working Draft, ANS X9.59‑199X, "Account‑Based Secure Payment Objects," Sep. 25, 1998, pp. 1‑26. → claims 1, 29–43, 48–49.
• "Account Authority Digital Signature Model" web page (garlic.com/~lynn/aadsover.htm), after Nov. 8, 1997, captured 2001‑10‑02. → claim 1(a).
• Stewart, D., "Account Authority Digital Signatures…," www.garlic.com/~lynn/aadswp.htm. → claim 1(a).
• Arthur, D., "AADS Option for Buyer Authentication," Sep. 14, 1998, pp. 1‑3. → claims 1, 73–78.
• NACHA pilot materials (Jul. 23, 2001; Feb. 23, 2003) and Kutler, "Privacy Broker" (Oct. 8, 1998) → claims 1, 73–78.
• Standards/guidance: FIPS PUB 140‑1 (1994), 140‑2 (2001), 180‑1 (1995), 186‑2 (2000), 190, 196, 113; NIST SP 800‑2 (1991), 800‑21 (1999); X9.84‑2000 (biometrics); PKCS #1, #3, #5, #6, #8, #9, #10, #12, #15; ISO/X.509 material; TCPA TPM Security Policy v0.45 (Oct. 2000) and TCPA PC Implementation Spec v0.95 (Jul. 4, 2001); Common Criteria Smart Card Protection Profile v2.1d (Mar. 21, 2001). → These are the express §112/§103 underpinnings for claims 19–23 (hash/SHA‑1), 57–58 (device security characteristics), 75–76 (encryption). Note the TCPA documents are dated Oct. 2000 and Jul. 2001, i.e., around/after the Aug. 4, 2000 priority date — their §102 status is date‑sensitive.
• VeriSign/Entrust/RSA PKI white papers, ABA Digital Signature Guidelines Tutorial, Gerck "Overview of Certification Systems" (Jul. 18, 2000), Linn "Trust Models and Management in Public‑Key Infrastructures" (Nov. 6, 2000) → relevant to the patent's admitted CADS/PKI prior art (col. 1) and to claims 44–47.
• Stewart, D., and the AADS reply materials → the patent's own admitted starting point.

6. Bottom line

1. Most relevant reference overall: the "X9.59 Working Draft / Account‑Based Secure Payment Objects" (Sep. 25, 1998) together with the "Account Authority Digital Signature Model" web page and Stewart's AADS paper — because they are pre‑1999 §102(b) art that describes exactly the architecture of claim 1's first‑account half (public key held by, and bound to, an account at an account authority; signed instruction authenticated against that key).
2. Most relevant single U.S. patent citations: US 5,677,955 (Doggett, EFT instruments), US 5,903,882 (Asay, trusted infrastructure), US 6,029,150 (Kravitz), US 5,790,677 (Fox), US 5,659,616 (Sudia) — each reads on claim 1's first‑account elements and on claims 31–33/39–42, but none was shown to bind the same public key to two separate account identifiers, which is claim 1's distinguishing feature.
3. Most relevant art on the "person‑centric"/multi‑account aspect: US 5,590,197 (Chen, "cyber wallet" — expressly a multi‑card, multi‑issuer package) together with US 5,781,723 (Yee, self‑identifying portable device with manufacturer security records). On the record retrieved, these are §103 material against claims 1, 81 and 82–91 rather than clean §102 anticipation.
4. Caution on dates: the priority date is 2000‑08‑04; roughly twenty listed references issue after that date and cannot be §102(a)/(b) art. Neither Google Patents nor the reproduced front‑page listings supply filing dates for every cited patent, so a definitive §102(e) determination requires pulling each application's filing date from USPTO PatentCenter/Global Dossier. I did not do that for every reference here, and I am flagging that as an unverified gap rather than asserting a conclusion.

Caveats: I verified the identity of US 6,978,369, its claim text, and the complete citation list; I verified the content of only four cited references by opening them (US 5,590,197, US 5,778,072, US 5,781,723, and the X9.59/AADS listings). Claim‑mapping statements for the remaining references are analytical inferences from titles/listing metadata and should be confirmed against the actual documents before being relied upon in any filing or validity opinion.

I'll research the prior art cited on this patent's page before building the § 103 analysis.

Let me pull the actual reference list and the claims.

I need the complete cited-reference list and the actual claim language. Let me retrieve those.

Obviousness Analysis — U.S. Patent No. 6,978,369 B2

Person-centric account-based digital signature system (Wheeler & Wheeler; First Data Corp.; provisional 60/223,076 filed 2000‑08‑04; PCT filed 2001‑08‑06; § 371 national stage 10/343,678; granted 2005‑12‑20)

1. Sourcing notes and limits on this analysis

I want to be explicit about what I could and could not verify, because it materially affects how much weight to put on any single piece below.

Two more framing points:

• The Google Patents page shows "Cited By (72)." Those are forward citations (e.g., US20020138418A1, US20030041262A1). They postdate the 2000‑08‑04 priority date and are therefore not § 102/103 art against the '369 claims. Do not use them as prior art; they are useful only as evidence of what the field was doing.
• Google lists legal status as "Expired – Lifetime, expires 2021‑11‑28." A § 103 analysis of the '369 claims is therefore largely retrospective/defensive, or relevant to later‑expiring family members. That does not change the technical analysis.

2. Governing framework and critical date

Pre‑AIA §§ 102/103 apply (effective filing date before 2013‑03‑16). Because the earliest U.S. filing is the provisional of 2000‑08‑04, the § 102(b) statutory-bar date is 1999‑08‑04. References published/otherwise public before 1999‑08‑04 are § 102(b) art usable in a § 103 combination without any antedating; references public between 1999‑08‑04 and 2000‑08‑04 are § 102(a) art (available for § 103 under pre‑AIA 103(a), but potentially sworn behind under Rule 131).

This matters: the two most on‑point items on the face of the patent predate the § 102(b) bar — the "Account Authority Digital Signature Model" web page (asserted available after 1997‑11‑08) and the ABA X9.59‑199X working draft, "Account-Based Secure Payment Objects" (1998‑09‑25). Both are more than one year before 1999‑08‑04... actually both are earlier than 1999‑08‑04, so they fall squarely in § 102(b). Note also that under pre‑AIA § 102(b) an inventor's own publication is a statutory bar — the AADS web page and white paper are Lynn Wheeler's own material and are still usable.

3. The claim scope being analyzed

From the patent's own summary passage, claim 1 (first aspect) is directed to:

• E1 — maintaining information pertaining to an account in an account database so it is retrievable by a unique identifier;
• E2 — associating a public key of a public‑private key pair with that unique identifier;
• E3 — generating a digital signature for an electronic message with the corresponding private key, the message containing an instruction and the unique identifier;
• E4 — authenticating the message using the public key associated with the information identified by the unique identifier;
• E5 — upon successful authentication, executing the instruction against the account;
• E6 — the "person-centric" limitation: the above is performed "for each of two separate accounts maintained by separate third parties."

Plus dependent/related subject matter: unique identifier = the public key or a hash of it; no "identity" information in the message; unencrypted transmission over an insecure medium; account information (balance, available credit, name, address, SSN, TIN, associated accounts); device profile / security characteristics of the device; a Central Key Authority (CKA) database holding third‑party account identifiers bound to a user's public key; and session vs. transaction vs. transaction‑confirmation uses of the EC.

The prior-art keywords Google indexes for this patent (account, message, information, authority, private key) track E1–E5 almost verbatim — a useful signal that the claimed combination is the assemblage of those five ordinary elements.

4. Reference inventory (as listed on/around the page), grouped by teaching

Group I — Account/issuer record keyed by account number, with public-key cryptography

• US 5,453,601 (Rosen, 1995‑09‑26) and US 5,557,518 / US 5,745,886 (Rosen, 1996/1998) — electronic‑monetary/trusted‑agent systems in which an issuing institution maintains value/account records and transactions are authenticated with public‑key cryptography via intermediaries. (High confidence on subject matter; medium on precise claim-level content.)
• US 5,724,424 (Gifford, 1998‑03‑03) — network financial transaction system with a payment/authorization intermediary.
• US 5,677,955 (Doggett et al., 1997‑10‑14) — electronic funds transfer instruments; signed payment orders tied to an account and a public key.
• US 5,590,197 (Chen et al., 1997‑01‑14) / US 5,694,471 (Chen et al., 1997‑12‑02) / US 5,781,723 (Yee et al., 1998‑07‑14) — IC/smart‑card electronic payment with on‑card keys.

Group II — Digital certificates / certification authority (CADS/PKI), which the patent itself characterizes as prior art (FIG. 1)

• US 5,659,616 (Sudia, 1997‑08‑19) — secure use of digital signatures in a commercial cryptographic system with a certificate hierarchy.
• X.509 / PKI generally (discussed in the patent's own Background).

Group III — "Account Authority Digital Signature" (AADS) materials, i.e., the inventor's own pre‑critical‑date publications

• "Account Authority Digital Signature Model" web page (garlic.com/~lynn/aadsover.htm), asserted available after 1997‑11‑08.
• ABA X9.59‑199X, "Account‑Based Secure Payment Objects," 1998‑09‑25.
• Stewart, D., "Account Authority Digital Signatures: Enabling Secure Internet Transactions via Existing Payment Processes & Infrastructure" (aadswp.htm). (Date not shown in the retrieved text — must be pinned down.)

Group IV — Smart‑card security / multi‑application cards

• Chan, "An Overview of Smart Card Security"; Taschler, "Technical Introduction to CIP 3.0" (1997‑09‑30); "Smart Cards: Enabling Smart Commerce in the Digital Age," CREC/KPMG White Paper (May 1998); O'Mahoney, Electronic Payment Systems (Artech House).

Group V — Trusted computing / tamper‑resistant modules

• US 5,502,766 (Boebert et al., 1996‑03‑26); US 5,509,071 (Petrie, 1996‑04‑16); US 5,422,953 (Fischer, 1995‑06‑06) — secure/tamper‑resistant cryptographic hardware and protected key storage. (Medium confidence on exact content.)
• TRUSTED COMPUTING PLATFORM ALLIANCE, TPM Security Policy v0.45 (Oct 2000) and TCPA PC Implementations Specification v0.95 (Jul 4, 2001) — cited and incorporated by reference in the spec, but post‑date the 1999‑08‑04 bar, so § 102(a)/103‑support only.

Group VI — Session/proxy and multi‑account infrastructure

• US 5,708,780 (Levergood et al., 1998‑01‑13) and US 5,715,314 (Payne et al., 1998‑02‑03) — network transaction servers/proxies mediating between users and multiple merchants.

5. Combination 1 — Core ABDS claims: Rosen + AADS publications (strongest combination)

Mapping. Rosen '601/'518/'886 supplies E1 (institutional account/value records), E2 (cryptographic keys bound to accounts), E4 and E5 (cryptographic verification of a transaction instruction before the institution acts). The AADS web page / Stewart white paper make the transfer explicit: the account authority — not a separate certification authority — records the customer's public key against the account record, retrieves it by account identifier, authenticates the signed message, and executes the instruction, with no certificate in the message. That is E1–E5 in the order claimed. Group IV references supply E3 (a card that generates the signature over a message).

Motivation (this one is unusually well supported). The '369 specification itself recites the failings of CADS that motivate the combination: certificate expiration ("an expired digital certificate generally is not recognized in the industry"), the revocation/CRL cross‑referencing burden, the need for a trusted third‑party relationship with a CA, and the exposure of identity information in the message. Where the specification articulates the problem the claimed solution addresses, that statement is itself evidence of the motivation. Additionally, the AADS publications expressly propose moving the key binding to the account authority precisely to eliminate the certificate layer, and the concurrent X9.59 standardization effort by the ABA shows the industry was actively pursuing account‑based secure payment objects. Under KSR, this is the paradigm case: a known cryptographic technique (signing) applied to a known business record structure (account database) with a predictable result.

Caveat. E4/E5 as claimed are tied to the account identifier lookup, not to a certificate; a petitioner must show the AADS reference discloses that lookup, not merely that both parties use public keys.

6. Combination 2 — The "person‑centric" limitation (E6): AADS/X9.59 + multi‑application card art + Rosen

E6 (one public key used against two separate accounts maintained by separate third parties) is the element the AADS materials alone do not plainly supply — AADS is institution‑specific. The gap is fillable:

• Group IV (Taschler, Technical Introduction to CIP 3.0; CREC/KPMG White Paper; Chan) discloses a single IC card holding one credential set and servicing multiple applications/accounts across issuers — the multi‑application card was the central theme of the 1997–98 smart‑card literature.
• X9.59 is framed around account‑based payment objects usable across accounts and issuers, i.e., a single cardholder authenticator with many account relationships.
• Rosen discloses a single value module/agent transacting with multiple issuers.

Motivation. One device, one key, one PIN, no per‑account enrollment of separate credentials; reduced key/credential administration and reduced user error. Also a straightforward extension of the artifact the industry already produced (a multi‑application chip card). The patent itself concedes at column‑level that using one PuK across two accounts at a single institution is "beneficial… when an account holder maintains a plurality of accounts," which frames the across‑institution case as a mere scaling of the same idea.

This is the vulnerable joint in the chain. A patent owner will argue hindsight: nothing in AADS or X9.59 teaches two separate third parties independently each binding the same public key to their own account identifier. That argument is answerable, but it requires an explicit secondary reference teaching one key across separate institutions, plus a reason. Multiapplication‑card art supports one card over multiple accounts; it is weaker on whether each separate institution independently performs the E2 association. A petitioner should look for a payment‑network/switch reference or a "shared authentication across affiliated institutions" reference to close this.

7. Combination 3 — CKA (Central Key Authority) claims: AADS + directory/proxy art

The CKA claims require a database holding (i) a user device's public key and (ii) third‑party account identifiers, each identifying to a third party an account that the third party has associated with the user's public key.

• Rosen '518/'886 (trusted agents mediating between otherwise‑unaffiliated issuers) supplies the intermediary repository of key/account bindings.
• Levergood '780 supplies a network server maintaining user records used to mediate transactions with multiple remote merchants.
• Ordinary PKI directory/X.509 repository practice supplies the concept of a queryable public‑key directory.

Motivation. Solve key discovery across institutions without bilateral agreements: an intermediate party or a second institution cannot know a sender's public key from an account number alone unless some shared registry exists. The patent's own discussion of the three‑party ABDS system (intermediate party forwarding the same message and signature to the account authority) frames exactly that problem.

Caveat. The specific "associated with the user's public key by the third party" registry semantics is narrower than a generic certificate directory; generic directory art may not literally disclose third‑party‑originated binding. This is where the claim's novelty most plausibly resides.

8. Combination 4 — Device profile / security‑features claims: AADS + trusted‑hardware art + smart‑card security literature

Claims directed to recording, per device, a public key plus the device's security features, and identifying those features to a recipient of the signature, are met by: Boebert '766 / Petrie '071 / Fischer '953 (tamper‑resistant modules, protected private keys, key‑generation inside the module) combined with the AADS account‑record structure, informed by Chan's smart‑card security survey and the CREC/KPMG white paper's discussion of card assurance levels.

Motivation. Standard risk management: the value a signature can support depends on the assurance that the key was protected and the signer verified — an idea the smart‑card literature already made explicit before the critical date. Note the TCPA/TPM documents are dated Oct 2000/Jul 2001 and therefore cannot support § 102(b); they are at best § 102(a) art or evidence of the level of ordinary skill.

9. Combination 5 — Intermediate party / transaction‑confirmation claims

Three‑party ABDS (holder → intermediate party → account authority, with the same message and signature forwarded) is squarely disclosed by Levergood '780 / Payne '314 (proxy/merchant‑server forwarding to a payment authority), combined with AADS. Transaction confirmation (re‑entry of a PIN, or deliberate modification of a proposed message before signing) is met by ordinary two‑factor authentication practice: ATM/POS PIN entry (O'Mahoney; Group IV) plus the Group I payment references. Motivation: the patent itself explains that a signature can be generated "without the desire or even knowledge of the owner," which is exactly the pre‑existing rationale for two‑factor confirmation.

10. KSR framing for the motivations

1. Specification admissions. The Background and Summary concede the deficiencies of CADS/PKI. Where the patentee identifies the problem and the art already proposes the same solution framework (AADS/X9.59), the motivation is not speculative.
2. Known elements, known functions, predictable result. Public‑key signing + account database + IC card. KSR holds that combining familiar elements according to known methods, with no change in function, is obvious.
3. Industry pressure / standardization. The ABA's X9.59 effort to standardize account‑based secure payment objects is objective evidence of a known design direction — the antithesis of the "teaching away" defense.
4. No teaching away. The certificate‑based art does not disparage account‑based key binding; the two coexist.
5. Design incentive / cost. Eliminating CA enrollment, certificate lifecycle management, and CRL checking is a recognized cost and liability reduction.

11. Where an obviousness case is weakest (and what to verify)

1. E6 (two accounts, two separate third parties). Needs a strong secondary reference. Without it, the "person‑centric" claims survive on the gap. This is almost certainly the point of novelty the examiner allowed over the cited art.
2. Proof of public accessibility for the AADS web page. The § 56 listing says the page is "believed available… after Nov. 8, 1997," with a capture date of 2001‑10‑02. That belief is an assertion, not evidence. A petitioner needs Internet Archive captures or corroborating testimony, otherwise the reference cannot carry a § 102(b) date.
3. Date of the Stewart AADS white paper. Not shown in the retrieved text; if it is 2000 or later it is § 102(a) at best and antedatable.
4. Post‑bar NPL items. The List Serve postings dated 1999‑12 through 2000‑04 and the TCPA documents (Oct 2000, Jul 2001) are after the 1999‑08‑04 bar; they are § 102(a)/skill‑level evidence only and may be sworn behind with the 2000‑08‑04 provisional.
5. Verbatim claim text. Rerun this analysis against the issued claims and the file wrapper before relying on it. I could not retrieve the literal claims in this session, and the element mapping above is reconstructed from the printed summary.
6. Priority‑date discrepancy to be aware of. One third‑party aggregator (Unified Patents) lists the priority date as 2000‑08‑03 while the Google Patents page states 2000‑08‑04. I am not correcting either; just note that any art falling on 2000‑08‑03/04 must be treated carefully.

12. Bottom line

The claims of US 6,978,369 are, on their face, the assembly of elements each independently known before the 1999‑08‑04 § 102(b) bar: (i) account records keyed by an account number and held by the account‑holding institution (Rosen '601/'518/'886; Gifford '424; Doggett '955); (ii) public‑key signing by a card‑resident key (Group I and Group IV); and (iii) the express proposal to bind the public key at the account authority and drop the certificate (the AADS web page, the Stewart white paper, and the ABA X9.59‑199X draft). Combination of (i)–(iii) renders the non‑person‑centric claims (E1–E5, session/transaction/confirmation, device‑profile, and the intermediate‑party variants) reasonably likely obvious, with the strongest motivation supplied by the patent's own criticism of CADS and by the contemporaneous X9.59 standardization effort.

The legs that need additional, verified art are the "two separate accounts maintained by separate third parties" limitation and the CKA third‑party‑binding claims; those should be attacked with multiapplication‑smart‑card art, payment‑network/switch art, and shared‑directory art, with the reviewer confirming both the reference disclosures and the docum