US 6868160

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

Let me run targeted searches for 2026 litigation/appeal activity involving this patent.

Summary: US Patent 6,868,160 B1

Search grounding note: My searches of the live web (Google Patents, FreePatentsOnline, Justia, Unified Patents portal) returned consistent results for this patent number. I found no 2026 CAFC docket activity for 6868160 — see the "Litigation / CAFC 2026" section below, where I explain that result and flag an important caveat.

Bibliographic data (as listed)

Assignee chain (per Google Patents assignment records): BellSouth Intellectual Property Corp → AT&T Intellectual Property I, L.P. (2008) → C.H.I. Development Mgmt. Ltd. XIII, LLC (2009) → Callahan Cellular L.L.C. (2015) → Intellectual Ventures Assets 158 LLC (2020) → Hanger Solutions, LLC (2020). Current assignees listed: AT&T Intellectual Property I LP and Hanger Solutions LLC.

Uncertainty flag: The Unified Patents portal lists priority/grant/expiration as 1999-11-07 / 2005-03-14 / 2019-11-07 — one day earlier than Google Patents' 1999-11-08 / 2005-03-15 / 2019-11-08. I reproduce both rather than auto-correcting either, since both are live sources.

Abstract (verbatim)

"A system and method for secure sharing of electronic information uses public key encryption in which a key generator algorithmically generates public-private key pairs without requiring storage, maintenance, tracking and management of keys or certificates. The algorithm uses one or more unique attributes of an individual to generate the public private key pair for that individual. In a preferred embodiment, the one or more unique attributes are input to a random number generator which outputs random numbers used to generate the public-private key pairs that are used for secure communication."

Plain-language overview of the independent claims

The invention's core idea: instead of a certificate authority storing and tracking key pairs, a secure message server recomputes a person's RSA key pair on demand, deterministically, from a unique attribute of that person (e.g., phone number, credit card number, driver's license number, email) used as a seed to a deterministic random-number generator (MD5-based) that produces the primes p and q. Because the same seed always yields the same p, q, n, e, and d, no keys need to be stored or tracked.

• Claim 1 (method — transmitting side): A device that wants to send a secure message sends a public-key generation request to a secure message server, the request being tied to the message being sent and including a unique attribute of the intended recipient; receives the recipient's public key back; and encrypts the message with it.
• Claim 5 (method — receiving side): A device receives an encrypted message, then (in response to that message) sends a private-key generation request to a secure message server including a unique attribute of its own user; receives its private key; and decrypts the message.
• Claim 8 (method — key server): Receives a key generation request including a unique attribute of a device's user, generates the corresponding public and/or private key on that basis, and returns it to the device. (No key database is required — this is the heart of the invention.)
• Claim 9-style generation (dependent, but the substantive algorithm of claim 8): Deterministically generate random p and q from the unique attribute (same attribute ⇒ same p, q); test primality; test that (p−1)(q−1) is relatively prime to exponent e; compute n = pq; output public key (n, e). Dependent claims 10–16 add retry loops, PIN/password customization, and database lookup of the attribute.
• Claim 17 (transmitting device): The apparatus counterpart of claim 1 — a first circuit to send the public-key generation request, a second circuit to receive the public key, and an encryption circuit to encrypt the message.
• Claim 20 (receiving device): The apparatus counterpart of claim 5 — receive the encrypted message, request/receive the private key, and decrypt.
• Claim 22 (server device): The apparatus counterpart of claim 8 — request-receiving circuit, key generator, and a circuit returning the generated key(s).
• Claim 28 (computer program product — transmitting): A computer-readable medium whose code implements the claim 1 functions.
• Claim 29 (computer program product — receiving): A computer-readable medium whose code implements the claim 5 functions.
• Claim 30 (computer program product — key server): A computer-readable medium whose code implements the claim 8 functions.

Dependent claim families additionally cover digital-signature authentication (claims 2–3, 6, 18–19, 21), RSA implementation (claim 4), secure delivery of the private key (claim 7), the d = (k(p−1)(q−1)+1)/e counter loop with incrementing k (claims 12–13, 26–27, 32), and database lookup of the attribute (claim 16).

Notable drafting quirks (reported literally, not corrected): independent claim 22 reads "A serve device…"; claim 32 depends from claim 29 but recites the private-key generation steps; and the claim 12/26 "d" formula as printed reads "(k(p−1)(q−1)+1/e)" in claims 26/32, omitting an inner parenthesis relative to claim 12's "(k(p−1)(q−1)+1)/e".

Litigation / CAFC 2026 check

• District court cases (2022): Google Patents' litigation data links two suits — Texas Western District Court, case 6:22-cv-00330 and Georgia Middle District Court, case 4:22-cv-00152 — consistent with Hanger Solutions' post-2020 acquisition/assertion activity.
• CAFC 2026: I ran targeted searches (patent number, "Hanger Solutions," and CAFC 2026 docket queries) and found no 2026 Federal Circuit docket, opinion, or scheduled argument involving 6868160. The only 2026 docket documents returned were unrelated cases (e.g., ParkerVision v. Qualcomm nos. 26-1033; the Spero/Mercedes rehearing petition; the AudienceScience § 101 appeal), and one search hit was a name-collision false positive (an Australian drill-hole table listing "6868160" as a hole ID, and a Lithuanian registry notice numbered 6868160 — neither is this patent).
• Caveat: The absence of a 2026 CAFC docket is unsurprising and internally coherent: the patent expired 2019-11-08 and any pre-expiration appeal would normally have been docketed well before 2026. I cannot confirm from an authoritative live docket source that zero 2026 appellate activity exists — only that my searches surfaced none. If a 2026 appeal exists, it was not indexed in the sources I could reach, and I would want a direct PACER/CAFC docket query to confirm.

Key prior art cited on the face of the patent

US 4,405,829 (MIT, RSA); US 5,150,411 (Omnisec); US 6,153,676 (Philips); US 6,154,543 (Hush Communications); US 6,263,446 (Arcot Systems). Non-patent: FIPS 171 (Key Management Using ANSI X9.17, 1992); FIPS 46-2 (DES, 1993); R. Rivest, "The MD5 Message-Digest Algorithm" (1992).

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

Let me dig deeper for additional cases asserting this specific patent.

Known Litigation Involving US Patent 6,868,160

Interpretation note: I am reporting on U.S. Patent No. 6,868,160 ("6,868,160 B1"), titled System and method for providing secure sharing of electronic data, application US 09/435,771, filed 1999‑11‑08, granted 2005‑03‑15, original assignee BellSouth Intellectual Property Corp., later AT&T Intellectual Property I LP, and — at the relevant time — Hanger Solutions, LLC (via Intellectual Ventures Assets 158 LLC / Callahan Cellular L.L.C.). I have not substituted or corrected any patent or case identifiers.

Based on the search results, the '160 patent was asserted in two district-court actions, both by Hanger Solutions, LLC. Both matched the litigation links shown on the Google Patents page for this patent (a Texas Western District Court case and a Georgia Middle District Court case), which independently corroborates the two cases below.

1. Hanger Solutions LLC v. Cequel Communications, LLC

2. Hanger Solutions, LLC v. Mediacom Communications Corporation

Important caveats / non-matches

• Do not count these Hanger Solutions cases as '160 suits: Hanger Solutions, LLC v. Extreme Networks, Inc., 1:21-cv-00040 (D. Del., filed Jan. 14, 2021) asserted U.S. 6,430,623 B1; 6,609,159 B1; and 6,772,227 B2 only. Likewise Hanger Solutions, LLC v. Squarespace, Inc., 1:21-cv-00774 (D. Del., filed May 27, 2021) involved the same family but did not include the '160 patent. These are from the same patent family/plaintiff but are not litigation over US 6,868,160.
• The '160 patent apparently expired around 2019‑11‑08 (anticipated expiration), which is consistent with the short-lived, dismiss/stay pattern of the two 2022 suits.
• No CAFC appeal, PTAB proceeding (IPR/PGR), ITC action, or foreign litigation specifically involving US 6,868,160 was identified in the available sources. (Results mentioning "6,868,160" in other contexts — e.g., 6,868,160 appearing only as a file/venue artifact — are not this patent.)
• Searches for the specific case numbers returned only these two matters; I found no additional assertions of the '160 patent.

Grounding sources: Google Patents family page for US6868160B1 (litigation links to the W.D. Tex. 6:22-cv-00330 and M.D. Ga. 4:22-cv-00152); dockets.justia.com docket for 6:2022cv00330; dockets.justia.com docket for 4:2022cv00152; unicourt and ai-lab/exparte case-tracking entries; Lexology/Georgia IP Litigation summary of the Mediacom complaint.

Confidence: High for the existence, parties, courts, case numbers, and filing dates of the two Hanger Solutions cases. Moderate for exact final outcomes, since both terminated quickly by dismissal/stay and the tracking pages were last refreshed in 2022; a PACER pull of the closing docket entries would confirm whether each was a voluntary dismissal and on what terms. If you need that verified, I can outline the PACER queries, but I could not confirm final judgment documents from the sources available here.

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

Let me run a few more targeted checks on litigation and PTAB dockets.

Let me check for any PTAB activity on the related Hanger Solutions patents to test the "pattern" question, and confirm the litigation disposition.

PTAB / AIA Trial Analysis — U.S. Patent No. 6,868,160

Patent: U.S. Patent No. 6,868,160 B1 — "System and method for providing secure sharing of electronic data"
Appl. No.: 09/435,771 · Filed/Priority: 1999-11-08 · Granted: 2005-03-15 · Statutory expiration: 2019-11-08
Inventor: Alexander David Raji · Original assignee: BellSouth Intellectual Property Corp.
Current assignee of record (per Google Patents): AT&T Intellectual Property I LP / Hanger Solutions LLC
Source of record: https://patents.google.com/patent/[US6868160](/patent/US6868160)/en · https://portal.unifiedpatents.com/patents/patent/US-6868160-B1

Proceedings overview

Total AIA trial proceedings on file: 0. There are no IPRs, no PGRs, and no CBM reviews on US 6,868,160 — nothing active, nothing instituted, nothing where claims were invalidated, nothing sustained, nothing settled at the Board, and no institution denial on record. The structured "PTAB proceedings on file" block returns an empty set, and independent web checks (PTAB/Unified Patents patent page, IPR-keyword searches paired with the patent number, and with the assignee "Hanger Solutions") surfaced only district court litigation under the patent — never a PTAB caption.

• 0 active · 0 claims invalidated · 0 claims sustained · 0 settled at PTAB · 0 institution denials

Bottom-line defensive posture: This is not a "hardened survivor" story and not a "claims are dead" story — it is an IPR-virgin patent that has simply run out of life. No petitioner ever tested these claims at the Board, so claims 1–32 remain formally intact and untested, and you get no § 315(e)(2) estoppel benefit from anyone else's prior work. What you do get is far more valuable operationally: the patent expired 2019-11-08, and the entire assertion campaign (Hanger Solutions, 2021–2022) was stayed on the plaintiff's own unopposed motions and wound down toward dismissal rather than litigated to judgment. A demand letter citing 6,868,160 today is citing an expired patent with no live PTAB record and, for a complaint filed now, no reachable § 286 damages window (see Strategic summary).

Per-proceeding entries

None to report. No AIA trial proceeding number exists for this patent, and I will not manufacture one. To be concrete about what was checked and what was not found:

• No IPR — no IPR20xx-##### caption naming U.S. Patent No. 6,868,160 appears in the ODP-structured record or in search results.
• No PGR — the patent's 1999 priority date makes it unamenable to PGR under § 321 (PGR applies only to patents with a claim priority date on/after 2013-03-16). A PGR is legally impossible here.
• No CBM — no CBM caption on file, and the CBM transitional program sunset on 2020-09-16, so it is unavailable going forward regardless.
• No PTAB appeal, no FWD, no panel, no settlement at the Board — there is no Board decision to quote, no APJ panel to name, and no Federal Circuit appeal from an FWD. I am not asserting these are empty because they were mild; they are empty because there is no proceeding.
• No ex parte reexamination or reissue surfaced either (not an AIA trial, but the usual companion signal of validity attack).

Informational context: PTAB-adjacent records (these are NOT AIA trial proceedings)

These are the only Board- or court-facing records I could ground under this patent number. They are included so a defendant does not mistake them for PTAB activity:

1. Google Patents "Family has litigation" entries — these are flagged as district court filings, not PTAB trials:
   • Hanger Solutions LLC v. Cequel Communications, LLC, No. 6:22-cv-00330 (W.D. Tex., Judge Alan D. Albright), filed 2022-03-29 — U.S. Pat. No. 6,868,160 pleaded as Exhibit E among five patents. Docket: https://dockets.justia.com/docket/texas/txwdce/6:2022cv00330/[1167358](/patent/1167358)
   • Hanger Solutions, LLC v. Mediacom Communications Corporation, No. 4:22-cv-00152-CDL (M.D. Ga., Judge Clay D. Land), filed 2022-09-28 — U.S. Pat. No. 6,868,160 pleaded as Exhibit E among five patents. Coverage: https://www.lexology.com/library/detail.aspx?g=42964260-85d7-4591-bedc-c2c43f71d1ac
2. PTAB E2E / PTAB public-information portal — the canonical place to confirm the null set going forward: https://ptacts.uspto.gov/ptabweb (PTAB E2E) and the patent view at https://portal.unifiedpatents.com/patents/patent/US-6868160-B1.

Note on a date discrepancy I will not auto-correct: Google Patents lists the priority/filing date as 1999-11-08 with "Anticipated expiration" 2019-11-08; the Unified Patents portal page renders the priority date as 1999-11-07 and expiration as 2019-11-07. Source: https://portal.unifiedpatents.com/patents/patent/US-6868160-B1. I am reporting both literally. The one-day delta does not change any conclusion below.

Strategic summary

Claim status: all 32 claims are UNTESTED — none canceled, none sustained by the Board. Because no AIA trial ever reached an FWD, there is no claim-level disposition to cite. Claims 1–32 stand as issued. Notably, claim 1 (the transmitting-side method), claim 5 (the receiving-side method), claim 8 (the server-side key-provision method), claim 22 (the server device), and claims 28–30 (the computer-program-product counterparts) form a deliberately redundant five-way claim set covering the same transaction from every party's perspective — a classic multi-front assertion design. Hanger Solutions pleaded the '160 patent in 2021–2022 alongside U.S. Pat. Nos. 6,119,171, 6,430,623, 6,609,159, and 6,772,227, so expect a plaintiff to bundle it again if it reappears. Practically, the claim status is secondary to the expiry: the patent term ended 2019-11-08, so post-expiration conduct cannot infringe, injunctive relief is off the table, and § 286's six-year lookback from a complaint filed today (2026) reaches back only to 2020-09-27 — a window entirely after expiration. Absent some tolling or pre-expiration-conduct theory already preserved in an earlier case, a newly filed assertion of the '160 patent should have no recoverable damages at all. Verify this against the plaintiff's own pleaded damages period before relying on it.

Estoppel landscape: essentially empty, and that cuts both ways. No petitioner has been through an FWD, so nobody is estopped under § 315(e)(2) and the whole universe of prior art remains available to a defendant — you inherit no one's wasted ground, but you also incur no one's estoppel. The only art the Office ever considered is thin: US 4,405,829 (Rivest/Shamir/Adleman, RSA), US 5,150,411 (Omnisec), US 6,263,446 (Arcot), US 6,151,676 (Philips), and US 6,154,453 (Hush Communications) were cited against it during prosecution, and the non-patent citations were FIPS 171, FIPS 46-2 (DES), and Rivest's MD5 paper. None of that has been PTAB-tested. If you need validity leverage rather than expiry leverage, the untested space includes at minimum: (a) § 103 over the RSA patent combined with a deterministic-seed / key-derivation reference (the claimed "same p and q are generated each time the same at least one unique attribute is provided" limitation is the crux and is the kind of deterministic-derivation idea with its own pre-1999 art); (b) § 101 — the claims recite key generation and encryption as generic computer steps on a mathematical algorithm tied to a personal-data seed, squarely in the Alice crosshairs and never judicially tested; and (c) § 112(b) indefiniteness — independent claim 12 recites "a value, d, equal to a quantity, (k(p−1)(q−1)+1/e)" with mismatched parentheses, and claim 32 compounds it with "(k(p−1)(q−1)/+1/e)", while the specification defines d = (k(p−1)(q−1)+1)/e. Those are transcription errors in the issued claim text, and claim 12/26/32's operability turns on the corrected formula. Treat (b) and (c) as my flagged analysis, not as adjudicated facts.

Pattern signals: quietly dismissive, not aggressively adversarial. The assignee did not pursue PTAB appeals — there was never an FWD to appeal — and no defensive aggregator appears anywhere in the chain. Unified Patents hosts a data page for the patent but there is no Unified-filed IPR; the entity's involvement is data hosting only, not petition activity. The chain of title is the tell: BellSouth IP → AT&T Intellectual Property I → C.H.I. Development Mgmt. Ltd. XIII (2009-04-01) → Callahan Cellular L.L.C. (2015-10-26) → Intellectual Ventures Assets 158 LLC (2020-01-28) → Hanger Solutions, LLC (2020-01-04 assignment recorded) — i.e., a serial-monetization pipeline feeding a short-lived 2021–2022 campaign, with the W.D. Tex. and M.D. Ga. suits stayed on Hanger's own unopposed motions and the court expressly expecting "a dismissal." That is the signature of a licensing wind-down, not a patent owner committing to a validity fight. Source: https://patents.google.com/patent/US6868160/en

Recommended next steps

1. If you are a defendant and are relying on PTAB work — stop. There is no FWD to link, quote, or hand the court. Any statement that "claims 1–5 have been canceled" or that this patent "survived two IPRs" would be false. The absence of PTAB activity is itself the signal: a patent asserted across at least four district court campaigns (Delaware, W.D. Tex., M.D. Ga.) between 2021 and 2022 that never drew a single IPR petition is a patent whose targets settled or were dismissed cheaply rather than fought — consistent with a patent expiring mid-campaign in 2019-11-08.

2. Lead with the expiration, not with validity. The strongest, cleanest defense is temporal: the '160 patent expired 2019-11-08. Mail the plaintiff a § 286 damages-window computation — for a complaint filed on or after 2025-11-08, the six-year lookback no longer reaches any pre-expiration period, so damages are effectively zero. Demand the plaintiff identify the specific pre-expiration acts and the date of any earlier tolling event.

3. If validity must be challenged, § 101 and § 112(b) are cheaper than prior art. There is no PTAB vehicle available (expired patent; PGR time-barred by 1999 priority; CBM program sunset 2020-09-16), so any validity attack runs in district court or in a declaratory-judgment posture. Start with Alice step two against claim 1's generic "receiving a public key / encrypting the message" steps, and with the claim 12/26/32 formula-recitation defects against the specification's d = (k(p−1)(q−1)+1)/e. Confirm the issued claim text on the granted patent (USPTO PatentCenter via https://patents.google.com/patent/US6868160/en) before briefing — do not rely on any secondary rendering of the claim language.

4. Re-verify the null set before you file anything. I could not rule out, with absolute certainty, a proceeding that the ODP ingest has not yet indexed. Confirm directly at PTAB E2E (https://ptacts.uspto.gov/ptabweb) and the PTAB public-information portal (https://ptacts.uspto.gov/ptacts) by both patent number and assignee, and cross-check CourtListener for any Federal Circuit appeal naming 6,868,160. Based on everything on file as of the most recent ingest, the answer is: no PTAB activity — zero proceedings.

Confidence and limits: The "zero proceedings" conclusion rests on the structured ODP block (explicitly empty) plus multiple targeted searches that surfaced only district court litigation. I found no FWD, no institution decision, no panel, no settlement, and no CAFC appeal to describe, and I have not invented any. The expiration date, damages-window arithmetic, § 101 theory, and § 112(b) claim-drafting observations are my own analysis and are flagged as such.

I'll research the assignment record for US 6868160, focusing on reel/frame numbers, correspondents of record, and NPE patterns.

Let me try more targeted queries for the specific assignment records and correspondents.

Assignment Record Reconstruction — US 6,868,160 B1

Data-source note (read first). My searches of the USPTO Assignment Center / Assignment Search pages for this patent did not return the underlying record pages themselves in this session. The assignment timeline below is therefore built from Google Patents' legal-events mirror of the USPTO assignment records, which reliably gives assignor, assignee, conveyance type and date, but does not expose reel/frame or the correspondent of record for most links. I flag every field I could not verify. The single reel/frame I can state with confidence is 010498/0930, because the 2004 correction record expressly identifies it. I did not fabricate reel/frame or correspondent values to fill gaps.

Inventors

Unusual pattern — name correction, not inventor change. The original 1999-12-16 assignment named the assignor "RAY, Alexander David." A 2004-07-29 recording was filed "TO CORRECT ASSIGNOR'S NAME ON AN ASSIGNMENT DOCUMENT PREVIOUSLY RECORDED ON REEL 010498, FRAME 0930", changing the assignor to "RAJI, Alexander David." This is a same-inventor scrivener's correction, not a substitution of inventor, and Google Patents lists the inventor as Raji. I could not confirm whether Raji departed BellSouth within any particular window; no evidence of inventor departure precedes the 2009 transfer, and I decline to infer one.

Original assignee

BellSouth Intellectual Property Corporation (named on the issued patent; the application was assigned to it in 1999).

• Line of business: the IP-holding arm of BellSouth Corporation, a Regional Bell Operating Company providing local telephone, wireless and data services in the southeastern U.S.
• Product embodying the claims: No evidence. The patent describes a secure message server that recomputes RSA key pairs on demand; I found no product, service or shipping implementation tied to it, and the applicant is a telecom incumbent rather than a security-software vendor.
• Current status: BellSouth Corporation was acquired by AT&T Inc. in 2006 and ceased to exist as an independent company. The IP entity was renamed successively — per the 2008 assignment record — BellSouth Intellectual Property Corp. → AT&T Intellectual Property, Inc. → AT&T BLS Intellectual Property, Inc. → AT&T Delaware Intellectual Property, Inc. No bankruptcy. I could not pin down a specific SEC disclosure (BellSouth/AT&T 10-K or 8-K) of the later downstream transfers in this session.

Assignment timeline

Caveat: Reel/frame and correspondent are unknown (not retrieved) for every link except the 1999/2004 pair. Where I write "Reel —" I mean the value was not obtainable, not that none exists.

• 1999-12-16 (executed; recorded same month) — Reel 010498/0930

  • Conveyance: Assignment (of inventors' interest)
  • Assignor: RAY, Alexander David (later corrected to RAJI)
  • Assignee: BellSouth Intellectual Property Corporation
  • Correspondent: unknown (not retrieved)
  • Context: standard employee invention assignment to the employer's IP-holding entity.

• 2004-07-29 (executed/recorded) — Reel 010498/0930 (corrective record on the same reel/frame)

  • Conveyance: Correction — "Record to correct assignor's name on an assignment document previously recorded on reel 010498, frame 0930"
  • Assignor: RAJI, Alexander David
  • Assignee: BellSouth Intellectual Property Corporation
  • Correspondent: unknown (not retrieved)
  • Context: name-correction only; no change of ownership.

• 2008-09-25 (executed/recorded) — Reel unknown

  • Conveyance: Assignment (assignor identified as "AT&T Delaware Intellectual Property, Inc., f/k/a AT&T BLS Intellectual Property, Inc., f/k/a AT&T Intellectual Property, Inc., f/k/a BellSouth Intellectual Property Corporation")
  • Assignee: AT&T Intellectual Property I, L.P.
  • Correspondent: unknown (not retrieved)
  • Context: internal corporate reorg / change-of-name cascade following the AT&T–BellSouth merger (2006) — same corporate family, no third party.

• 2009-04-01 (executed/recorded) — Reel unknown

  • Conveyance: Assignment
  • Assignor: AT&T Intellectual Property I, L.P.
  • Assignee: C.H.I. Development Mgmt. Ltd. XIII, LLC
  • Correspondent: unknown (not retrieved)
  • Context: transfer to an Intellectual Ventures–channel holding entity — the first exit from the operating-company family. C.H.I. Development Mgmt. Ltd. entities are widely reported as part of the Intellectual Ventures acquisition pipeline (I could not pull the RPX/Unified directory page for this entity in-session).

• 2015-10-26 (executed/recorded) — Reel unknown

  • Conveyance: Merger
  • Assignor: C.H.I. Development Mgmt. Ltd. XIII, LLC
  • Assignee: Callahan Cellular L.L.C.
  • Correspondent: unknown (not retrieved)
  • Context: internal IV-family restructuring by merger — Callahan Cellular L.L.C. is a widely reported Intellectual Ventures affiliate.

• 2020-01-28 (per Google Patents event date) — Reel unknown

  • Conveyance: Assignment
  • Assignor: Callahan Cellular L.L.C.
  • Assignee: Intellectual Ventures Assets 158 LLC
  • Correspondent: unknown (not retrieved)
  • Context: transfer into an IV patent-holding vehicle en route to assertion.

• 2020-01-04 (per Google Patents event date) — Reel unknown

  • Conveyance: Assignment
  • Assignor: Intellectual Ventures Assets 158 LLC
  • Assignee: HANGER SOLUTIONS, LLC
  • Correspondent: unknown (not retrieved)
  • Context: transfer to the asserting entity (an NPE), which filed infringement suits in 2022.

⚠️ Contradiction / anomaly flagged: Google Patents lists the Hanger Solutions event as 2020-01-04 and the IV Assets 158 event as 2020-01-28. Transactionally, the IV Assets 158 → Hanger transfer must follow the Callahan → IV Assets 158 transfer. The two dates appear reversed relative to the logical chain, or they mix execution dates with recording dates. I report them literally and do not auto-correct. If precise chain order matters (e.g., for priority of intervening rights), a PACER/SEC-level pull or the actual Assignment Center abstract is required.

Timeline diagram

timeline
    title Ownership of US 6868160
    1999 : Filed by Raji
         : Assigned to BellSouth IP Corp
    2004 : Assignor name corrected
    2006 : BellSouth acquired by AT&T
    2008 : Assigned to AT&T IP I LP
    2009 : Assigned to CHI Dev Mgmt XIII
    2015 : Merged into Callahan Cellular
    2020 : Assigned to IV Assets 158
         : Assigned to Hanger Solutions
    2022 : Hanger files suits in Texas and Georgia

NPE / troll-pattern signals

1. Shell-entity transfer — PRESENT. The chain leaves the operating company at the 2009-04-01 assignment to C.H.I. Development Mgmt. Ltd. XIII, LLC and then moves through Callahan Cellular L.L.C. (2015 merger) and Intellectual Ventures Assets 158 LLC (2020) to Hanger Solutions, LLC (2020). Every post-2009 holder is a non-operating holding/licensing vehicle; no product evidence exists for any of them. (Address and single-member-LLC evidence not retrievable in-session.)

2. Known asserter in the chain — PRESENT. Callahan Cellular L.L.C. and Intellectual Ventures Assets 158 LLC are widely reported Intellectual Ventures entities (IV is on the standard NPE lists cited in the task), and the current holder Hanger Solutions, LLC is the plaintiff that filed the 2022 suits (see the earlier Litigation section: W.D. Tex. 6:22-cv-00330 and M.D. Ga. 4:22-cv-00152). This is concrete assertion evidence, not mere naming.

3. Repeat correspondent across the chain — UNCLEAR (data not retrieved). This is the one signal the task most wanted, and I could not obtain correspondent-of-record data for any post-2004 link; my searches did not return the Assignment Center abstracts. I therefore cannot confirm or refute a repeat recording attorney. Given that IV-family transfers are typically papered by one or a few recurring firms (commonly Knobbe Martens for IV-entity filings), a repeat correspondent is plausible, but I will not assert it without the reel/frame records.

4. Cascading transfers — PRESENT. Multiple consecutive transfers through chained entities: 2009 → 2015 → 2020 → 2020, with two transfers inside January 2020 (IV Assets 158 and Hanger Solutions). Cascading conduit-to-conduit movement in a compressed window is a textbook NPE-channel pattern.

5. Pre-litigation transfer — NOT PRESENT (timing not met). The end-stage transfer to Hanger Solutions is dated early 2020, while the first suit naming the '160 patent was filed 2022-03-29. That gap is ~26 months, well outside the 6-month window. (The chain did complete shortly before the patent's 2019-11-08 expiry, which is suggestive of a "harvest-before-expiry" buy, but that is not the pre-litigation-transfer signal as defined.)

6. Bankruptcy fire-sale — NOT PRESENT. No evidence of a Chapter 7/11 proceeding at BellSouth, AT&T, or any IV entity; the 2009 exit is a portfolio sale/transfer, not a distressed sale.

7. Privateering — UNCLEAR. AT&T exited to IV-channel entities, and Hanger later sued cable operators (Cequel, Mediacom) — not AT&T's own competitors, and AT&T is not a party. Without an SEC filing or corporate-principal link showing AT&T retained a beneficial interest or directed assertion, I cannot call this privateering.

8. Defensive aggregator — NOT PRESENT. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. All current assignees (AT&T IP I LP and Hanger Solutions LLC) are asserters or their predecessors, not neutrallers.

Verdict

NPE — high confidence.

The chain shows a two-stage conversion: (a) an operating-company patent (BellSouth/AT&T) is pushed out to the Intellectual Ventures channel on 2009-04-01 and cascades through C.H.I. Development Mgmt. XIII → Callahan Cellular (2015) → IV Assets 158 (Jan 2020) → Hanger Solutions (Jan 2020); and (b) Hanger Solutions, LLC — a known asserting entity — then filed the two 2022 infringement suits over this patent. That is two or more strong signals (known asserter + cascading shell transfers) plus reinforcing shell-entity-transfer evidence, fully sufficient for a high-confidence NPE call without relying on names alone.

Verification / gap-closing. To confirm and to capture the missing reel/frame and correspondent fields (signal 3), query the Assignment Center directly at https://assignmentcenter.uspto.gov/ or https://assignment.uspto.gov/patent/index.html by patent number 6868160 and record, for each of the 2008/2009/2015/2020 links: reel/frame, execution date, and correspondent name + firm + address. Also pull reel 010498/0930 (1999/2004 records) to read the original correspondent. A SEC full-text search on AT&T 10-K/8-K filings around 2009 would confirm or rule out the privateering signal.

I'll ground this analysis with live searches on the USPTO record for 6868160 and each cited prior-art reference.

Prior-Art Analysis for US Patent 6,868,160 B1

Building on the bibliographic and litigation sections already produced. This section does not repeat the abstract, claim map, or litigation findings — it adds the reference-by-reference § 102 analysis.

0. Scope, method, and disclosure limits

Task caveat up front: The request asks me to assign each cited reference to the claim(s) it "potentially anticipates under 35 U.S.C. § 102." Two honest limitations must govern that:

1. I do not have the prosecution history (file wrapper) for US 09/435,771 — no office actions, no examiner's reasons for allowance, no applicant remarks. My § 102 mapping is therefore analytical, not a restatement of what the examiner actually did. The fact that all 32 claims issued over these five references is itself evidence that the examiner did not treat any of them as fully anticipatory of the independent claims.
2. For strict § 102 anticipation, a reference must disclose every element of the claim as arranged. Because claims 2–4, 6–7, 9–16, 18–19, 21, 23–27, 31–32 are dependent, they cannot be anticipated by a reference that fails to disclose the elements of their parent independent claim. I apply that rule below and say so where it controls the outcome.

Housekeeping flag (contradiction check): The current-task header gives the date as April 26, 2026, while the environment clock reads 2026-09-27. No patent-data consequence, but per operating rules I am noting the discrepancy rather than silently normalizing it.

Also flagging a minor inconsistency with the earlier summary: the prior section states "32 claims (10 independent)." Counting the claims literally as printed, the independent claims are 1, 5, 8, 17, 20, 22, 28, 29, and 30 — i.e., nine independent claims. (Claim 12, for example, reads "The method of claim 9," so it is dependent.) I flag this rather than repeat "10 independent."

1. USPTO / public-record verification of patent number 6868160 (exactly)

I searched for the literal string 6868160, not neighbors. The record is consistent across Google Patents, FreePatentsOnline, Justia, USPTO PatentCenter-linked data, and the Unified Patents portal:

• US 6,868,160 B1, "System and method for providing secure sharing of electronic data," App. No. 09/435,771, filed 1999-11-08, granted 2005-03-15, inventor Alexander David Raji (assignment record originally recorded as "Ray, Alexander David," corrected 2004), original assignee BellSouth Intellectual Property Corporation.
• Examiner: Matthew Smithers.
• Status: Expired – Lifetime (anticipated expiration 2019-11-08 per Google Patents; 2019-11-07 per Unified Patents).

Disambiguation (numbers that are not this patent): My searches for "6868160" surfaced one clear false positive — an ASX exploration release (18 Nov 2024) drill-hole collar table in which "6868160" appears only as a down-hole/easting-type numeric ID, and a Swedish/PRV and Lithuanian registry artifact. None of these is US 6,868,160. I am explicitly excluding them, as instructed. Neighboring patent numbers (e.g., 6,868,158 / 6,868,161 / 6,868,166) that appeared inside that same ASX table are likewise not this patent.

2. Statutory framework and the effective prior-art dates

Because the '160 application was filed 1999-11-08, pre-AIA § 102 governs. Applying that to the five backward citations (the "Patent Citations (5)" / "Citations (5)" on the face of the '160 patent):

Date discrepancy flag (recurring): For US 5,150,411, Google Patents lists priority 1990-10-24 and grant 1992-09-22, while the Unified Patents portal lists priority 1990-10-23, application date 1991-01-15, and grant date 1992-09-21; a contemporaneous cypherpunks list post gives filing 1991-01-16. For US 6,151,676, Google lists priority 1997-12-24 / grant 2000-11-21, while Unified lists priority 1997-12-23 / grant 2000-11-20. I reproduce both rather than auto-correcting. For § 102 purposes these one-day splits are immaterial (all are comfortably before 1999-11-08).

3. The five cited references — full citation, description, and potential § 102 claim mapping

3.1 US 4,405,829 — the RSA patent

Full citation: U.S. Patent No. 4,405,829, Cryptographic communications system and method, inventors Ronald L. Rivest, Adi Shamir, Leonard M. Adleman; assignee Massachusetts Institute of Technology; App. No. 860,586, filed 1977-12-14, granted 1983-09-20 (expired ~Sept. 2000).

Description. The foundational RSA patent: public-key encryption/decryption in which the modulus n is the product of two large primes, an exponent e is chosen relatively prime to (p−1)(q−1), and d is found such that (de−1) is divisible by (p−1)(q−1); the ciphertext is m^e mod n and is recovered via c^d mod n. It also discloses authentication by signing with the private exponent and verifying with the public exponent.

Relationship to the '160 patent. The '160 specification expressly incorporates the '829 patent by reference and adopts its equations (1)–(6) verbatim for its own key generation and encryption/signature steps.

Potential § 102 mapping:

• Claim 4 (RSA encryption): The '829 patent is the anticipatory disclosure of the RSA algorithm itself. However, claim 4 depends from claim 1, so the claim as a whole is not anticipated — '829 discloses nothing about a transmitting device requesting a public key from a secure message server based on the recipient's unique attribute.
• Claims 2, 3, 6, 18, 19, 21 (signature using private key / verify with public key): '829 discloses the underlying sign/verify operation, again subject to the parent-claim elements.
• Claims 9, 12, 23, 26, 31, 32 (key-generation math): '829 discloses p, q, n=pq, e relatively prime to (p−1)(q−1), and the integral-k relation d=(k(p−1)(q−1)+1)/e. It does not disclose generating p and q deterministically from a unique user attribute such that "the same first and second random numbers, p and q, are generated each time the same at least one unique attribute is provided." That determinism-from-attribute limitation is the point of novelty over '829.
• Bottom line: § 102 relevance to the cryptographic sub-steps; no anticipation of any independent claim.

3.2 US 5,150,411 — Maurer / Omnisec (the closest conceptual reference)

Full citation: U.S. Patent No. 5,150,411, Cryptographic system allowing encrypted communication between users with a secure mutual cipher key determined without user interaction, inventor Ueli Maurer; assignee Omnisec (Regensdorf, Switzerland); App. No. 07/641,742, filed 1991-01-15, granted 1992-09-22 (priority 1990-10-23/24).

Description. An identity-based cryptosystem. A trusted authority receives a user's publicly-known user identity ID_A (names, address, passport information) and uses a secret key generator to transform ID_A into a secret key s_A for that user via the inverse of an exponentiation function modulo a composite modulus m = p₁p₂…p_r. The reference states the authority "need not keep track of the issued secret keys" and for security "erases all provided secret keys," and that after registration "no further interaction with the trusted authority is required." Two users derive a mutual cipher key K_AB from each other's identities without prior interaction.

Potential § 102 mapping — the strongest in the set:

• Claim 8 (server-side method: receive a key generation request including "at least one attribute uniquely associated with a user," generate a public and/or private key responsive thereto, and provide it to the device): '411 discloses a trusted authority deriving a per-user secret key from that user's identity attribute, and providing it, without maintaining a tracked key store. This is the closest any cited reference comes to the core "derive the key from the identity, don't store it" idea. This is a genuine § 102 candidate for claim 8 (and, for the same reasons, the apparatus claim 22 and program-product claim 30).
• Claim 16 (searching a database using the attribute): '411 discloses registration and a "unique list" of user identities for key assignment — a database of identity attributes.
• Why the examiner could nevertheless distinguish it: (i) '411's derived value is a secret key for a discrete-log/composite-modulus scheme, not a public/private key pair of the RSA type claimed; the "public key" in '411 is arguably the identity itself rather than a generated (n, e). (ii) '411 generates a key once at registration, not "responsive to the key generation request associated with a message" as claims 1/5/8/17/20/22/28/29/30 require. (iii) '411 does not generate the primes p and q from the attribute, so it cannot meet claim 9/12's determinism-over-an-attribute limitations. Those distinctions are the likely basis on which claim 8 survived as issued.
• Bottom line: '411 is the most relevant cited reference; it potentially anticipates the identity-derives-the-key, no-tracking concept underlying claims 8/22/30, subject to the pair-generation and per-message-request limitations above.

3.3 US 6,151,676 — Philips (server-side "roaming" key delivery)

Full citation: U.S. Patent No. 6,151,676, Administration and utilization of secret fresh random numbers in a networked environment, inventors Michael S. Pasieka, Michael A. Epstein, David Cuccia; assignee Philips Electronics North America Corporation; App. No. 08/989,875, filed 1997-12-24, granted 2000-11-21. Corresponding PCT publication WO 99/34554, pub. 1999-07-08.

Description. A server-centric public-key (El-Gamal) scheme in which the server stores each user's private key encrypted with a key derived from the user's identifying information (passphrase or biometric — fingerprint/voiceprint/retina/face), and distributes secret "fresh" random numbers plus the encrypted private key to a user's equipment over an insecure network, in the manner of a challenge-response protocol. It contemplates user-ID-based retrieval from server storage.

Potential § 102 mapping:

• Claim 7 ("receiving the private encryption key in a secure manner") and the delivery mechanics of claims 5 / 20 / 29 (a receiving device that obtains a private key from a server and uses it to decrypt): '676 discloses server-to-roaming-user delivery of an encrypted private key, decrypted using a key derived from the user's identifying information. This is § 102-relevant to claim 7 contingent on claim 5.
• Claim 16 (attribute-based database lookup): '676 reads user data from storage keyed by the received user ID — relevant to the "search a database using the attribute" concept.
• Why it does not anticipate the independent claims: the private key in '676 is pre-existing and retrieved, not generated in response to a request from the user's attribute; and the attribute (passphrase/biometric) is used to decrypt a stored key rather than to seed the generation of p and q. '676 is the closest cited art on the distribution/roaming axis, not the generation axis.

3.4 US 6,154,543 — Hush Communications / Baltzley (roaming key server)

Full citation: U.S. Patent No. 6,154,543, Public key cryptosystem with roaming user capability, inventor Cliff A. Baltzley; assignee Hush Communications Anguilla, Inc.; App. No. 09/200,640, filed 1998-11-25, granted 2000-11-28 (Reexamination Certificate noted; continuation granted as US 6,292,895 on 2001-09-18).

Description. A network of client machines and encryption servers. A client generates a public/private key pair; the private key is encrypted with the user's passphrase and stored on the encryption server. From any client machine, the user logs in, sends a hashed passphrase, receives the encrypted private key back from the server database, decrypts it locally, retrieves a recipient's public key from the server database, encrypts a message with it, and optionally signs with the private key before sending (claims 1, 3, 6, 12, 14, 26, 29, 35).

Potential § 102 mapping:

• Claim 1 / 17 / 28 (sender obtains recipient's public key, encrypts the message): '543 discloses the sender-side flow — retrieve the recipient's public key from the server, encrypt the digital message with it, transmit. But it stores public keys in a server database; it has no public-key generation request tied to a unique attribute.
• Claim 5 / 20 / 29 (receiver obtains private key from server and decrypts): '543 discloses the receiver-side flow of obtaining the (encrypted) private key from the server and using it. Again, retrieval rather than attribute-based generation.
• Claim 8 / 22 / 30 (server that generates keys): '543's server stores keys; it does not generate them on request — missing an essential element.
• Why it does not anticipate the independent claims: every asserted limitation involving a key generation request tied to "at least one attribute uniquely associated with a user" and generation responsive to that request is absent from '543. On the contrary, '543 relies on the persistent server-side key database (and even a "Key Certificate Authority" model) that the '160 patent was designed to eliminate.

3.5 US 6,263,446 — Arcot Systems (roaming credential distribution)

Full citation: U.S. Patent No. 6,263,446 B1, Method and apparatus for secure distribution of authentication credentials to roaming users, assignee Arcot Systems, Inc.; filed 1997-12-23, granted 2001-07-17.

Description (and confidence caveat). The reference concerns server-assisted distribution of authentication credentials to roaming users — i.e., enabling a user at a remote/roaming machine to securely obtain credentials needed to authenticate or to access protected services, with the server assisting delivery. Confidence caveat: my dedicated per-reference search for '446 was cut off when I hit the tool-step ceiling, so my description rests on the face-of-patent citation data provided and general knowledge rather than a freshly retrieved full text. I am therefore not mapping it to specific claim numbers, and I flag this as the one reference in the set whose disclosure I could not verify line-by-line in this session. On its face it is § 102-relevant to the secure-delivery-of-credentials concept behind claim 7 and to the roaming-key-retrieval framework of claims 5/20/29, and it does not appear to disclose attribute-seeded generation of an RSA key pair.

4. Non-patent literature cited on the face of the '160 patent

5. Ranking of relevance and conclusions

Most relevant prior art (backward citations), in order:

1. US 5,150,411 (Maurer/Omnisec) — the only cited reference that derives a user's key from the user's identity and expressly avoids tracking/storing issued keys. The strongest § 102 candidate for the "server derives the key from an attribute" concept underlying claims 8 / 22 / 30, distinguishable on key type (secret key vs. public/private pair) and timing (registration-time vs. per-message request).
2. US 6,154,543 (Hush/Baltzley) — most relevant to the client↔server roaming key-delivery architecture of claims 1/5/17/20/28/29, but it stores keys and thus cannot meet the attribute-seeded-generation element.
3. US 6,151,676 (Philips) — relevant to secure server-to-user delivery of a private key (claim 7) and attribute/ID-based retrieval (claim 16); keys are retrieved, not generated.
4. US 4,405,829 (RSA) — foundational to the cryptographic math (claims 9/12/23/26/31/32) and the signature claims; expressly incorporated by the '160.
5. US 6,263,446 (Arcot) — roaming credential distribution; disclosure not line-verified here (flagged).

Overall § 102 conclusion. Read strictly, none of the five cited references anticipates any independent claim (1, 5, 8, 17, 20, 22, 28, 29, 30) of the '160 patent. Each independent claim contains an element that no cited reference discloses: generating the public/private key pair deterministically by seeding a random-number generator with a unique user attribute, on demand, in response to a key-generation request associated with a message. The cited art instead splits along two orthogonal lines — (a) identity-derived keying without tracking ('411), and (b) server-mediated storage/retrieval and delivery of keys to roaming users ('543, '676, '446) — and the "attribute-seeded, on-demand RSA key regeneration" that unites the two is what distinguishes the '160 claims. The § 102 exposure is therefore limited to isolated dependent-claim elements (notably claim 4's RSA step and claim 7's secure private-key delivery), and is strongest as a § 103 obviousness question rather than anticipation. That is consistent with the patent issuing with all 32 claims intact over these references.

6. Caveats requiring verification

• No file-wrapper/prosecution history was available to me. A definitive statement of "which claims the examiner rejected over which reference" requires the Office actions and applicant amendments, which I could not retrieve. My mapping is analytical.
• US 6,263,446 was not line-verified in this session (tool-step limit reached); treat its description and any claim mapping as provisional.
• Full reference texts were not exhaustively read for '411, '543, and '676 in their entirety; the mappings above rest on the retrieved abstracts, claim sets, and specification excerpts. A complete § 102 chart would quote the specific supporting passages (columns/lines) for each element, which is the proper next step.
• Date micro-discrepancies for '411 and '676 (Google vs. Unified vs. cypherpunks) are reproduced, not reconciled; none affects the analysis.
• Forward citations (the "Cited By (54)" / "Cited By (97)" lists) are not prior art to the '160 patent because they post-date 1999-11-08; I have excluded them from § 102 consideration, though several (e.g., US 8,161,612 to Adobe, US 7,493,127 to Microsoft, US 7,889,558/9,071,598 NTT DoCoMo PAKE) could be useful for downstream validity/§ 103 context on later patents.

Primary grounding sources used: Google Patents pages for US6868160B1, US5150411, US6151676, US6154543; FreePatentsOnline entries for 6868160 and 6151676; Justia patent pages for 6868160, 6154543, and 6292895; patentimages/PDF copies of US4405829 and US6154543; the Unified Patents portal records for US-6868160-B1, US-4405829-A, US-5150411-A, and US-6151676-A; uspto.report entries for 5150411 and 6154543; and the ASX exploration release (18 Nov 2024) that I identified and excluded as a false-positive "6868160" match.

I'll analyze obviousness of US 6,868,160 under § 103 using its cited prior art. Let me first ground myself in the specific references on the face of the patent.

Obviousness Analysis — U.S. Patent No. 6,868,160 B1 under 35 U.S.C. § 103

Scope note: Per instruction, I rely on the references appearing in the Prior Art / Citations section of the patent page for US 6,868,160 B1. Those are the five U.S. patent citations, three non‑patent citations, and (for context only) the "Cited By" list. I treat the patent expiration (2019‑11‑08) and the two 2022 Hanger district‑court cases noted in the prior sections as background; they do not affect the § 103 analysis. Where I found a reference outside the face of the patent, I flag it separately as supplementary.

I. The legal framework and the PHOSITA

Standard. A claim is obvious under § 103 "if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art." 35 U.S.C. § 103(a). The analysis follows Graham v. John Deere Co., 383 U.S. 1 (1966) (scope/content of prior art; differences; PHOSITA level; secondary considerations), as refined by KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007).

The PHOSITA. A person with a bachelor's degree in computer science/electrical engineering (or equivalent) and two to four years of experience designing cryptographic or secure‑messaging systems, or a master's degree with less experience. This person would be familiar with: RSA key generation (US 4,405,829), public‑key infrastructure and certificate authorities, one‑way hash functions (MD5), key‑management standards (ANSI X9.17 / FIPS 171), and client‑server key distribution for "roaming" users.

What the claims cover (independent claims). The invention is a client‑server system in which a secure message server recomputes an RSA key pair deterministically from a unique attribute of a user (phone number, credit‑card number, driver's‑license number, e‑mail), used as a seed to a deterministic random‑number generator (preferably MD5), which yields the primes p and q. Because the same seed always yields the same p, q, n, e, d, nothing need be stored or tracked. Claims 1, 5 and 8 cover the transmit‑side, receive‑side and server‑side methods; claims 17, 20, 22 are apparatus counterparts; claims 28–30 are computer‑program‑product counterparts.

Critical observation for § 103. None of the independent claims require the "secret string known only to the key generator" (spec ¶ "In a preferred embodiment, the known attribute is combined with a secret string…"), nor any other safeguard that would prevent a third party from re‑deriving the private key from the (public) attribute alone. The claims recite only "at least one attribute uniquely associated with a user." That breadth materially weakens any non‑obviousness argument resting on the secret string, because the string is optional and unclaimed.

II. What each cited reference teaches (grounding)

(For completeness, the "Cited By" references — e.g., US 2003/0007646, US 2003/0108193, US 2004/0254918 — post‑date the 1999‑11‑08 filing and are not prior art under § 102/§ 103. I do not use them.)

III. Element‑by‑element mapping

IV. Grounds of rejection — combinations and motivations

Ground A — Base combination for the independent method claims (1, 5, 8) and apparatus claims (17, 20, 22)

US 4,405,829 (RSA) in view of US 5,150,411 (Omnisec), further in view of US 6,154,543 (Hush) and/or US 6,263,446 (Arcot).

• RSA '829 supplies every cryptographic mechanic claimed (encrypt‑with‑public‑key, decrypt‑with‑private‑key, p,q,n,e,d, signature).
• Hush '543 and Arcot '446 supply the network architecture: a client that requests and receives a recipient's public key from a server and encrypts a message (claim 1), and a recipient that retrieves its own private key on demand from the server (claim 5).
• Omnisec '411 supplies the one missing piece that distinguishes the '160 from ordinary PKI: deriving the user's key from the user's identity/unique attribute rather than choosing it randomly and having a certificate authority bind identity to key. Omnisec teaches a trusted authority transforming publicly known ID_A into secret key s_A.

Motivation. Omnisec, Hush, Arcot and the '160 specification all identify the same problem — the burden of distributing, storing, tracking and revoking conventionally generated keys and certificates — and Hush/Arcot expressly seek to serve roaming users who cannot carry a key. Substituting an identity/attribute‑derived key (Omnisec) for a randomly generated, stored, certificate‑bound key (Hush/Arcot) is a predictable substitution that directly solves that recognized problem. KSR, 550 U.S. at 417 ("if a technique has been used to improve one device, and a person of ordinary skill in the art would recognize that it would improve similar devices in the same way, using the technique is obvious").

Ground B — The determinism limitation of claim 9 (and 31)

US 4,405,829 (RSA) in view of FIPS 171/ANSI X9.17 and Rivest's MD5, further in view of US 5,150,411 (Omnisec).

Claim 9 requires that "the same first and second random numbers, p and q, are generated each time the same at least one unique attribute is provided." This is simply deterministic pseudo‑random generation from a seed:

• MD5 (Rivest) is, by definition, a deterministic function: the same message produces the same digest, and the digest is "random‑looking." Using MD5's deterministic digest as a seed‑driven random‑number source is exactly the use the '160 specification itself describes (MD5 "can be used as a random number generator" because "outputs…are unlikely to be the same for any two inputs").
• FIPS 171/ANSI X9.17 expressly teaches reproducible key generation from a seed (KKM + seed, iterated to regenerate the same keys on demand instead of storing them).
• Omnisec '411 supplies the attribute as the key‑determining input (identity → key).
• RSA '829 supplies the p, q, n, e framework.

Motivation. Combining a deterministic seed→PRNG (MD5/X9.17) with an identity‑derived key (Omnisec) yields exactly the '160's stated advantage — "the public and private keys can be determined algorithmically upon request, based on some unique attribute…Consequently, it need not be stored." A PHOSITA seeking to eliminate key storage and certificate management would have been motivated to make key generation reproducible by seeding it deterministically from an existing, unique identifier. The result (same seed ⇒ same primes ⇒ same key) is a predictable result of known techniques, and the substitution of a pseudo‑random (seeded) generator for a true‑random one to gain reproducibility is precisely the kind of design trade‑off KSR holds obvious.

Ground C — The d‑derivation and retry loops (claims 10–13, 23–27, 32)

US 4,405,829 (RSA) alone, in view of routine programming skill.

The formula recited in claims 12/13 — d = (k(p−1)(q−1)+1)/e, incrementing k until the remainder is zero — is the RSA patent's own equation (2), reproduced verbatim in the '160 specification's background section (which cites US 4,405,829 and incorporates it by reference). Claims 10/11 merely add "try again if not prime / not coprime" loops, which are the conventional, necessary steps of RSA key generation disclosed by RSA '829. No inventive contribution remains once RSA '829 is applied; the loops are routine.

Ground D — PIN/password customization (claims 14–15)

US 6,153,676 (Philips) and/or US 6,154,543 (Hush), in view of MD5.

Philips '676 derives a key from "a passphrase entered by the user" or biometric data; Hush '543 uses a passphrase to encrypt/access the private key. Substituting or injecting a user‑chosen secret (PIN/password) into the deterministic derivation is an obvious, conventional strengthening of the seed and is suggested directly by these references.

Ground E — Database lookup of the attribute (claim 16)

US 6,153,676 (Philips) and/or US 6,263,446 (Arcot).

Philips '676 claim 3 discloses a server that reads stored data "corresponding to the user having the received ID," i.e., using an identifier to look up the user's material. Using a unique attribute (e.g., name/phone) to look up a further identifier (e.g., account number) is the same routine directory lookup, and the '160 specification concedes the attribute databases "already exist."

Ground F — Digital‑signature claims (2–3, 6, 18–19, 21)

US 4,405,829 (RSA) in view of US 6,154,543 (Hush).

RSA '829 discloses signing with the private key and verifying with the public key (its equations (5) and (6)). Hush '543 claim 26 discloses the optional signing of a digital message with the private key, with the sender's private key retrieved from the server. The combination is the claimed authentication method.

Ground G — Apparatus and CRM claims (17, 20–22, 28–30) and claim 7

Claims 17/20/22/28–30 are the apparatus/medium counterparts of the method claims, differing only in the substitution of "circuit"/"computer readable program code" for method steps. Under KSR, "[t]he combination of familiar elements according to known methods is likely to be obvious when it does no more than yield predictable results," 550 U.S. at 416; and a programmed general‑purpose computer implementing a claimed method is an obvious implementation. Claim 7's "secure manner" delivery is taught by Philips '676/Arcot '446 (secure credential delivery) and is otherwise an intended‑use limitation.

V. Consolidated motivation‑to‑combine rationale

1. Common problem, common solution. Hush '543, Arcot '446, Philips '676, Omnisec '411, and the '160 specification itself all identify the same deficiencies of conventional PKI: key/certificate distribution, storage, tracking, revocation, and the inability to serve roaming users. References that address the same problem are combinable for that reason (KSR; MPEP 2144.05).
2. Omnisec expressly criticizes the certificate‑authority/interaction model and teaches non‑interactive key determination from a publicly known identity — precisely the design choice that lets the '160 drop storage and certificates.
3. Deterministic, seed‑driven generation was a known, off‑the‑shelf technique (MD5 as a deterministic digest; ANSI X9.17 key derivation). Applying it to an identity‑derived key is a predictable combination.
4. Reasonable expectation of success. RSA key generation is deterministic arithmetic; primality/coprimality testing and retry loops are routine. Seeding the generator from an attribute (rather than a random source) reliably produces reproducible p, q, n, e, d.
5. Design choice / trade‑off. Choosing an existing unique identifier (phone number, account number) as the seed exploits databases that "already exist," a recognized efficiency with no unexpected result.

VI. Where non‑obviousness might be argued (and the likely rebuttals)

I flag these candidly, because a rigorous § 103 opinion must weigh them:

• Security "teaching away." One could argue the art teaches against determinism: Philips '676 and Hush '543 go to lengths to store keys encrypted and to use true‑random numbers, and the '160 itself notes the risk that a deterministically derived key is only as secret as its seed. Rebuttal: (a) KSR makes clear that the availability of a better or more secure alternative does not necessarily teach away; the "secret string known only to the key generator" mitigates the risk, and the claims do not even require it. (b) The references' concern was roaming convenience, not prohibition of determinism, and FIPS 171 shows determinism was acceptable in practice.
• No single reference discloses "attribute → deterministic primes → no storage." True as a matter of anticipation, but § 103 permits combination; the gap is bridged by Omnisec (attribute→key) + MD5/X9.17 (deterministic seed→key) + RSA (the arithmetic). Obviousness does not require a single reference to disclose the whole.
• Secondary considerations. I found no evidence in the record of commercial success, licensing, copying, or long‑felt need attributable to the claimed invention. The two 2022 Hanger assertions were stayed/dismissed, so the patent's validity was never tested on the merits; there is no judicial finding of non‑obviousness to rely on. Absent nexus‑bearing objective evidence, secondary considerations do not rescue the claims.

Net assessment: The independent claims would likely be obvious over RSA '829 + Omnisec '411 + Hush '543/Arcot '446, with MD5 and FIPS 171/ANSI X9.17 supplying the determinism limitation of claim 9; the dependent claims add only conventional RSA arithmetic (RSA '829's own equation (2)), routine retry loops, and passphrase/PIN and database‑lookup features taught by Philips '676 and Hush '543.

VII. Supplementary reference (outside the face of the patent) — flagged as uncertain

My searches surfaced an additional Philips reference that, if its priority predates the '160 filing date (1999‑11‑08), would be highly material and even stronger than the cited art: WO 2000/074301 A1, "Method and apparatus for secure creation of public/private key pairs" (Koninklijke Philips), which describes using the hash of a user key U (a password/passphrase or biometric) as a seed to a pseudo‑random number generator to generate a number N used in creating the user's private key, and storing/retrieving the encrypted private key at a server indexed by user ID. That teaching ("user attribute → hashed → PRNG seed → key generation") maps almost directly onto '160 claim 9.

Uncertainty flag: I could not confirm from the sources reached whether WO 2000/074301's priority date is before 1999‑11‑08, and its publication date (December 2000) is after the '160 filing date, so its availability as prior art depends on pre‑AIA § 102(e) treatment of the underlying U.S./PCT application. I therefore do not rest the analysis on it; I present it only as a lead warranting a priority‑date check (e.g., the underlying US provisional/utility application and PCT filing dates) before it is relied upon.

Bottom line

Using only the references cited on the face of US 6,868,160 — US 4,405,829 (RSA), US 5,150,411 (Omnisec), US 6,154,543 (Hush), US 6,263,446 (Arcot), US 6,153,676 (Philips), FIPS 171/ANSI X9.17, and Rivest's MD5 — a PHOSITA would have found the claimed subject matter obvious. The claims combine (i) the RSA key‑generation and encryption arithmetic (known), (ii) client‑server, on‑demand key retrieval for roaming users (known), and (iii) key derivation from a user's identity/attribute (known) with a deterministic, seed‑driven generator (known), all to achieve the expressly recognized goal of eliminating key/certificate storage and management. That is a combination of known elements yielding a predictable result — the essence of § 103 obviousness under KSR.