Invalidity dossier
US 6463534
Secure wireless electronic-commerce system with wireless network domain
Current assignee: Motorola Mobility, Inc.
Added 9/26/2026, 3:44:46 AM
Active provider: DeepSeek · deepseek-v4-flash
Auto-generating section 1 of 2: Extensions…
Each section takes ~30-60s with web-search grounding. Keep this tab open — sections will fill in below as they complete.
Patent summary
Title, assignee, inventors, filing/issue dates, abstract, and a plain-language overview of the claims.
I'll search for the specific patent number in USPTO and CAFC docket sources.
The generic searches returned unrelated results (different patents). Let me run more targeted searches for the exact number and for CAFC 2026 docket activity.
US Patent 6,463,534 — Analyst Summary
⚠️ Search / Sourcing Note (read first)
I was asked to search the USPTO database and CAFC 2026 dockets for the literal number 6463534. What actually happened:
- CAFC 2026 docket searches returned zero results for "6463534" (both a direct CAFC-2026 query and a Federal Circuit appeal query came back empty). I therefore have no evidence of any Court of Appeals for the Federal Circuit 2026 proceeding involving this patent. Treat that as "not found," not as "confirmed none exists."
- Generic USPTO/web searches on the bare number returned noise — e.g., an unrelated patent 11,002,646 (Spectrum Solutions sample-collection IPR) and various foreign documents. Those are different numbers and I am discarding them per your rule against returning similar numbers.
- My primary source is the authoritative full text of US6463534B1 supplied in the prompt (Google Patents rendering, prior-art date 1999-03-26, grant 2002-10-08), plus limited corroborating hits confirming the number/title/assignee pairing (e.g., uspto.report/patent/grant/6463534).
Bibliographic Data (from the authoritative text)
| Field | Value |
|---|---|
| Patent number | US 6,463,534 B1 |
| Title | Secure wireless electronic-commerce system with wireless network domain |
| Application no. | US 09/276,978 |
| Filing date | 1999-03-26 |
| Priority / prior-art date | 1999-03-26 |
| Issue (publication) date | 2002-10-08 |
| Inventors | Robert L. Geiger; Jyh-Han Lin; Rajiv Mehta |
| Original assignee | Motorola, Inc. |
| Current assignee | Google Technology Holdings LLC |
| Assignment chain | Motorola, Inc. → Motorola Mobility, Inc. (2010-12-13) → Motorola Mobility LLC (2012-09-18, change of name) → Google Technology Holdings LLC (2014-11-13) |
| Legal status | Expired – Lifetime; anticipated expiration 2019-03-26 |
| Family / foreign filings | PCT/US2000/004470 (WO2000059225A1), EP00914658 (EP1166557A4), CN00805563 (CN1345514A), TW089103693 (TW469714B), AU36018/00 |
| Key CPC classes | H04L63/0823 (certificate-based entity authentication); G06Q20/3821 (electronic credentials); G06F21/10 (DRM); H04W12/069 (auth. using certificates); H04L2463/102 (security for e-commerce) |
Litigation flag in the authoritative record: the file lists a "Family has litigation" flag with two U.S. District Court, Southern District of Florida cases — 1:12-cv-20271 and 1:10-cv-23580 — and a Darts-ip worldwide-family-litigation reference (family 23058927). These are district-court (not CAFC) entries.
Abstract (as granted)
A method of conducting transactions in a wireless electronic commerce system, where the system comprises a wireless network operator certification authority (400) having a root public key certificate and at least one attribute authority (404, 405, 406) having a digital certificate that is dependent from the root public key certificate. The attribute authority is accessible by a wireless client device (450, 452) via a wireless network. The digital certificate is delivered from the attribute authority to the wireless device, the attribute authority is verified to the wireless client device using the digital certificate and the root public key certificate pre-loaded in the wireless client device under authority of the wireless network operator. An attribute (software, service, right/permission or other content item) is delivered to the wireless client device over the wireless network and ultimately enabled at the wireless client device.
Plain-Language Overview of the Disclosure
The specification is really two related disclosures stitched together:
FIGS. 1–3 — a certificate-based software distribution/fulfillment model. A phone leaves the factory pre-loaded with (i) the CA's public-key certificate, (ii) its own public-key certificate, (iii) one or more License Certificates (binding a product list to the phone's unalterable serial number), and (iv) one or more Product Certificates (binding a product name to a hash of the software). At boot, the phone validates product hashes and license/serial-number matches back to a trusted root. A later purchase through the web server (16) causes the CA server (15) to mint a new License Certificate — enabling already-installed but dormant software, or triggering a WTLS-encrypted download from the Software Server (17) via the WAP proxy (18).
FIGS. 4–5 — the "wireless network domain" PKI architecture. A wireless network operator CA (400) is the domain root. Merchants/content sellers — mobile phone manufacturer (404), book merchant (405), wireless software supplier (406) — act as Attribute Authorities (AAs) holding certificates dependent from the operator's root. The client (device 450 and/or its SIM 452, plus a WAP Identity Module/WIM) already holds the operator root certificate, so it can verify any AA. Payment can be made by the client presenting its own domain certificate (verified against the root), after which the AA instructs the billing computer (402) to add the charge to the customer's existing wireless bill (steps 550–560 in FIG. 5). The patent also describes cross-certified domains, inter-domain validation servers, attribute/merchant payload identifiers, time-limited attribute certificates, and electronic vouchers exchanged between AAs (links 408, 409) — e.g., a discount earned at AA 404 and redeemable at AA 405, either AA-to-AA or carried by the client.
Independent Claims — Plain-Language Reading
Uncertainty flag: The full literal claim set was not included in the authoritative excerpt I was given (the rendering jumps from "Description" to "Landscapes/Abstract"). The independent claims below are reconstructed from the Summary of the Invention and Detailed Description, which restate the claims almost verbatim. I am confident about the substance and number of independent claims; I am less certain about exact claim numbering and precise claim language. Verify against the USPTO PatentCenter / granted-claims text before relying on verbatim quotes.
1. Method of conducting transactions in a wireless e-commerce system (AA-verification + attribute delivery).
The system has a wireless-network-operator CA with a root public-key certificate, plus at least one attribute authority holding a digital certificate that depends from that root. The AA is reachable by a wireless client over the wireless network. Steps:
- deliver the AA's digital certificate from the AA to the wireless device;
- verify the AA at the client using that certificate together with the root public-key certificate pre-loaded in the client under the operator's authority;
- deliver an attribute (software, service, right/permission, or other content item) to the client over the wireless network; and
- enable the attribute at the client.
- Preferred/related: payment is transacted by the client sending a second digital certificate to the AA and the AA verifying it against the CA's root certificate.
2. Method using an electronic voucher between two attribute authorities.
Same domain structure, but with at least first and second AAs, each holding a certificate dependent from the operator root. Steps:
- establish wireless communication between the client and the first AA;
- deliver a first attribute to the client over the wireless network;
- generate an electronic voucher verifiable by the second AA;
- establish wireless communication between the client and the second AA;
- request a second attribute from the second AA;
- identify (present/recognize) the voucher at the second AA; and
- deliver the second attribute from the second AA to the wireless device.
- Related aspect: the voucher may travel AA-to-AA over a direct connection or via the wireless client.
3. Wireless electronic commerce system (apparatus claim).
Comprises: a wireless-network-operator CA server with a root public-key certificate; at least one AA server coupleable to the CA server with a digital certificate dependent from the root; a wireless client device pre-loaded with the root certificate; a wireless network coupling the client to the AA server; verification means in the client for verifying the AA's certificate using the pre-loaded root certificate; sending means (e.g., gateway 18/420) at the AA side and receiving means (e.g., radio receiver in device 450) for delivering an attribute over the wireless network; and means for enabling the attribute at the client.
4. Method of operating a wireless e-commerce system (certificate/record-keeping + enablement).
Steps: maintain at one or more servers digital content certificates (for content items) and digital license certificates (for licenses to those items); maintain, per wireless client, a record of licenses and of the content items associated with each license; establish communication between the server(s) and a wireless client device via a wireless gateway; deliver a content item to the device (device has a unique identifier in the system); verify the content item at the server; verify the associated license; and enable the content item at the client once both verifications pass.
- Related: license verification where a content-item name is pre-associated with the client's license certificate, or where the name satisfies a predefined rule (e.g., falls within a permitted version range, treating it as an upgrade of an already-licensed item).
- Related (may be separate/independent): content replication between devices — reloading content onto a second client, swapping the server-side association from the first client ID to the second client ID, re-verifying the licenses/certificates, so the second device assumes the first's functionality.
Likely dependent claims cover, among other things: pre-loading the client certificate into the SIM 452 or a WIM; sending an instruction from the AA to the operator's billing computer (402) to add the charge to the subscriber's bill; time-limited/expiring attribute certificates; and merchant payload identification schemes (organizational identifier, WAP OID, or domain-specific merchant ID scheme).
What I Could Not Establish
- No CAFC (2026 or otherwise) docket activity surfaced for 6463534 in my searches. The only litigation evidence in the record is two S.D. Florida district-court cases.
- Exact granted claim language and claim numbering — not present in the authoritative excerpt; my claim overview is a faithful paraphrase of the Summary/Description, not a verbatim reproduction.
- Because the patent's anticipated expiration was 2019-03-26 and status is Expired – Lifetime, any 2026 appellate activity would be unusual (e.g., a long-tail damages/remand matter), and I found none. I'd rather flag this as unknown than assert a negative I can't prove.
Recommendation for verification: pull the granted claims and any 2026 appellate filings directly from USPTO PatentCenter (application 09/276,978) and the Federal Circuit's PACER/CM-ECF docket, since my web searches did not reach those authoritative databases for the literal number 6463534.
Generated 9/28/2026, 3:32:48 PM
Cases on file (2)
Group view →Specific litigation cases in our database that name US patent 6463534. The free-form analysis below may also discuss cases beyond this list.
- Motorola Mobility, Inc. v. Apple, Inc.filed Oct 6, 20101:10-cv-23580U.S. District Court for the Southern District of Floridaclosed
Defendants: Apple, Inc.
- 1:12-cv-20271U.S. District Court for the Southern District of Florida
Litigation summary
Past and pending lawsuits — plaintiffs, defendants, jurisdictions, outcomes, and notable rulings.
I'll research litigation involving US patent 6463534 using the tools available.
Let me search the specific case numbers mentioned in the patent record and other litigation databases.
I found one case. Let me dig deeper on the 2012 case and verify which patents are involved in these suits.
Litigation Involving U.S. Patent No. 6,463,534
Sources consulted
- Google Patents record for US6463534B1 (the "Family has litigation" section), which links to Unified Patents' litigation portal
- Unified Patents litigation portal URLs cited on the Google Patents page
- Court records surfaced via Justia Dockets and the Florida Southern District (FLSD) docket
- CAFC and general web searches for the patent number
Note: my search session was cut off before I could exhaust verification, so I flag confidence levels explicitly below. I did not find any CAFC appeal or PTAB proceeding tied to this patent.
Cases identified
1. Motorola Mobility, Inc. v. Apple, Inc.
- Plaintiff: Motorola Mobility, Inc. (successor to original assignee Motorola, Inc.) — Confidence: high that this is the case at the cited docket number
- Defendant: Apple, Inc.
- Jurisdiction: U.S. District Court for the Southern District of Florida (Judge Ursula Ungaro, docket suffix "-UU")
- Case number: 1:10-cv-23580
- Filing date: October 6, 2010
- Cause of action: Patent infringement
- Outcome/status: Closed. (The docket shows an Apple answer/amended counterclaims filing; the case database lists status "Closed.")
- Caveat: Google Patents lists this docket under the 6,463,534 family's "litigation" data, and the caption/docket details are confirmed. However, Motorola asserted a large portfolio against Apple in this era, and I was not able to independently confirm from the documents retrieved that U.S. 6,463,534 was specifically named in the asserted patent list. Treat the patent-to-case linkage as based on the Google Patents/Unified Patents family-litigation data rather than a verified complaint citation.
2. Case No. 1:12-cv-20271
- Jurisdiction: U.S. District Court for the Southern District of Florida
- Case number: 1:12-cv-20271
- Parties: Not confirmed. The Google Patents record cites this docket as litigation involving the 6,463,534 family, but the retrieved results did not yield a verified caption. A search result describing a Southern District of Florida patent case, University of Florida Research Foundation, Inc., et al. v. Motorola Mobility LLC (captioned as litigation over "wireless communications and emulation," status "settled in 2014"), is plausibly the same matter, but I could not confirm the case number or that 6,463,534 was asserted. Do not rely on this caption without independent verification.
- Filing date / outcome: Unconfirmed (the related description suggests a 2012 filing resolved around 2014).
3. "First worldwide family litigation filed" (Darts-IP)
- The Google Patents page also links a Darts-IP "first worldwide family litigation" entry for family no. 23058927. I was unable to retrieve the underlying record, so I cannot state the jurisdiction, parties, or case number for any foreign proceeding. Confidence: low / unverified.
Summary
- Confirmed docket: One U.S. case is clearly documented — Motorola Mobility, Inc. v. Apple, Inc., No. 1:10-cv-23580 (S.D. Fla., filed Oct. 6, 2010), now closed.
- Second U.S. docket (1:12-cv-20271, S.D. Fla.): listed against the patent by the patent record, but parties, filing date, and outcome remain unverified from my searches.
- No CAFC appeal or PTAB/administrative challenge specific to U.S. 6,463,534 was found.
Recommended next steps for definitive confirmation
- Pull the actual complaints from PACER for both 1:10-cv-23580 and 1:12-cv-20271 to confirm whether 6,463,534 appears in the asserted-patent lists (a case may be listed in family data because of a related-portfolio assertion rather than direct assertion of this patent).
- Query Lex Machina, Docket Navigator, or Unified Patents' Portal directly by patent number.
- Check the USPTO PatentCenter "Litigation" tab and the Darts-IP family record (family 23058927) for the foreign filing.
Because of the strict no-fabrication requirement, I am explicitly declining to supply a caption, filing date, or outcome for the 2012 case and the Darts-IP entry that I could not verify.
Generated 9/28/2026, 3:32:45 PM
Proceedings on file (0)
All PTAB activity →AIA trial proceedings (IPR / PGR / CBM) filed at the USPTO Patent Trial and Appeal Board against this patent. Sourced from the USPTO Open Data Portal and refreshed every six hours; each proceeding number deep-links to the PTAB E2E docket.
Current assignee: Motorola Mobility, Inc.
No PTAB proceedings on file. This patent has not been challenged via IPR, PGR, or CBM. The absence is itself a signal — well-asserted patents eventually attract IPRs. The LLM analysis below may surface filings the ODP feed hasn’t indexed yet.
PTAB challenges
AIA trial proceedings at the USPTO Patent Trial and Appeal Board — IPR, PGR, and CBM. Petitioners, judge panels, claim-level invalidation outcomes from Final Written Decisions, and Federal Circuit appeals. The single most important defensive datapoint after litigation history.
I'll verify the structured data's "no PTAB activity" indication against live web sources before drafting.
Let me run targeted searches to confirm no AIA proceedings exist under alternate citation formats.
Let me do a final round of adversarial checks for any proceeding I might have missed (Apple IPRs, Unified Patents, CBM on the '534 patent).
Proceedings overview
Zero AIA trial proceedings are on file against US 6,463,534. The structured "PTAB proceedings on file" block — sourced from the USPTO Open Data Portal — returns no IPR, PGR, or CBM, and live web searching (Google Patents, Justia, PTAB document repositories) surfaced no proceeding number anywhere naming the '534 patent as the challenged patent; the only hits pairing the number with PTAB documents were other patents that happen to cite '534 as prior art, not proceedings against it. The defensive bottom line is unusual: the patent has neither been hardened by surviving an IPR nor narrowed by losing one — it is simply untested at the PTAB, and it is now expired (anticipated expiration 2019-03-26), so the live question for a defendant today is past-damages exposure, not injunctive risk.
Proceedings overview (detail)
| Metric | Count |
|---|---|
| Total AIA trial proceedings on file | 0 |
| Claims invalidated via AIA trial | 0 |
| Claims sustained via AIA trial | 0 |
| Settled / terminated | 0 |
| Institution denied | 0 |
| Active | 0 |
Plain-English gloss: There is no proceeding to grade, no FWD to quote, no estoppel to map, and no petitioner to worry about. Any statement purporting to describe an IPR/CBM outcome or a Federal Circuit appeal for this patent would be fabricated; none exists in the record I can verify.
No proceedings to report
I ran the adversarial checks that matter — IPR, PGR, CBM, reexamination, Apple's and Google's petition histories against Motorola wireless patents, and docket aggregators — and found nothing. Two nuances worth flagging so the picture is complete:
- The '534 patent does appear in PTAB records as prior art, not as the challenged patent. For example, Exhibit 1002 filed in IPR2024-00233 (Google LLC, re US 8,886,954) lists "6463534" in an interference/prosecution search history — that is a citation inside another party's exhibit, not a proceeding against '534. Do not misread that as PTAB activity on your patent.
- District court, not PTAB, is where this patent was fought. The structured data records two S.D. Fla. cases — 1:12-cv-20271 and 1:10-cv-23580 — and the associated litigation was Motorola Mobility v. Apple, in which "the '534 Patent" was charted against iOS/OSX devices, the App Store, and iTunes (see the claim-chart excerpt at docs.justia.com). Notably, Apple — a sophisticated, well-resourced defendant with a deep PTAB playbook — apparently did not petition for AIA review of this patent, even while the case was live. That absence is itself a signal: either the economics didn't justify the filing, the claims were not a viable long-term threat, or the parties resolved the dispute another way. I cannot confirm a disposition date for those cases from the sources available, so I will not guess one.
- Ownership changed hands. Original assignee Motorola, Inc. → Motorola Mobility → Google Technology Holdings LLC (2014-11-13). So any current assertion would run through Google, not a classic troll — relevant to the "troll has no case" framing.
Strategic summary
Claim-status map. Because no AIA trial issued, no claims of 6,463,534 are canceled and no claims are confirmed-sustained — the entire claim set was simply never tested at the PTAB. Claims 1 and 15 are the independent claims (a method claim and a "system comprising" means-plus-function claim, respectively); claims 2–14 depend from the method claim and 16–19 depend from the system claim. All of them are "untested," which is not the same as "strong." An untested claim is a black box: you have no PTAB precedent either way, which cuts both ways for a defendant.
Expiration is the dominant fact. The patent's anticipated expiration was 2019-03-26 and its legal status is Expired – Lifetime. That means: (i) no prospective injunctive relief and no ongoing-royalty theory — only past damages, and only for infringement within the six-year lookback of 35 U.S.C. § 286 measured to the complaint's filing date; and (ii) any demand letter today invoking the patent is limited to legacy product revenue. Independently, there is a serious § 101 question hanging over these claims (certificate/PKI transaction methods), but that ground was never adjudicated post-Alice on this patent.
Estoppel landscape. There is no § 315(e)(2) estoppel against anyone, because no petitioner ever reached a final written decision. So a defendant is not precluded from raising any prior-art ground — § 102 or § 103 — in district court or in a new IPR. The full universe of art is available. The corollary cost is that you'd be the first to test it, without the benefit of a prior FWD.
Pattern signals. No repeat-petitioner pattern (zero petitioners). No PTAB appeals by the patent owner (nothing to appeal). No defensive aggregator — the two S.D. Fla. cases are captioned Motorola Mobility v. Apple, i.e., an operating-company patent war, not a Unified Patents-style campaign. The strongest pattern read is negative: a high-value Motorola patent asserted against Apple in 2010–2012 that nonetheless drew no IPR and no CBM during the very window when Apple was filing dozens of both.
Confidence note: I am highly confident that no AIA trial proceeding exists on this patent (structured ODP data plus independent web verification agree). I am not confident about the precise filing/disposition dates or outcomes of the S.D. Fla. matters, and I have deliberately not supplied any — those are inference-limited and would require the docket itself (PACER) or CourtListener RECAP to confirm.
Recommended next steps
- Treat "no PTAB activity" as the answer. For any memo or opinion, state plainly: there are no AIA trial proceedings on US 6,463,534. The absence is a signal worth naming — a patent with this litigation pedigree that never attracted a single IPR/CBM is either commercially trivial or was resolved before the PTAB became a factor.
- Lead with expiration, not invalidity. The patent expired 2019-03-26 and is "Expired – Lifetime." Any asserted demand is capped at past damages under § 286. Confirm the demand's accused-act window falls inside the six-year lookback or you may have a damages-limitation defense independent of any invalidity theory.
- If the assertion is live, pull the two S.D. Fla. dockets — 1:10-cv-23580 and 1:12-cv-20271 — from PACER/CourtListener to determine (a) which claims of '534 were actually asserted, (b) whether the case settled, and (c) any claim constructions that could bind or help you. I could not verify dispositions from public web sources and will not speculate.
- Preserve the full invalidity arsenal. No estoppel attaches (no FWD ever issued), so § 102/§ 103 art is unrestricted. If you need a ground not yet litigated, a fresh ex parte reexamination or a new IPR remains procedurally open — though for an expired patent, weigh whether the damages exposure justifies the cost.
- Flag the § 101 angle as untested and potentially dispositive, given the claims recite certificate-authentication and payment transactions — but note it has never been adjudicated for this patent, so it is an argument, not a holding.
Verify-before-you-cite: The two court records above are linkable public dockets; the PTAB absence is verifiable directly at USPTO Patent Trial and Appeal Board by searching "6,463,534." I have not cited any FWD, appeal, or settlement because none exists for this patent.
Generated 9/28/2026, 3:33:00 PM
Ownership chain (4)
Asserters network →Structured records extracted from the assignment-history narrative below. Each entity links to its full ownership-network profile.
1999-05-17 · Assignment
? · recorded 2010-12-13 · Assignment
Motorola, Inc.Motorola Mobility, Inc.
internal reorg
? · recorded 2012-09-18 · Change of Name
Motorola Mobility, Inc.Motorola Mobility, Inc.
change of name only
? · recorded 2014-11-13 · Assignment
Motorola Mobility, Inc.Google Technology Holdings LLC
internal reorg
Assignment history
Inventors, original assignee, and the chain of ownership recorded with the USPTO — including the correspondent attorney who recorded each assignment, since shell-LLC chains often share one repeat-player attorney even when the entity names look unrelated. Surfaces NPE / patent-troll patterns: shell-entity transfers, known asserters in the chain, repeat correspondent fingerprints, pre-litigation assignments, and bankruptcy fire-sales.
I'll start by pulling the assignment records from USPTO and cross-referencing the ownership history.
Let me search for the litigation records and assignment database entries directly.
Ownership & Assignment Analysis — US 6,463,534 B1
Data-access note (read first): I could not retrieve the underlying USPTO Patent Assignment Search records for this patent. The Assignment Center / assignment.uspto.gov index is not crawlable by the search tools available to me, and no third-party mirror surfaced a reel/frame number, an execution/recording date pair, or a correspondent of record for any link in this chain. The chain below is reconstructed from the USPTO-derived Google Patents legal-events data supplied in the source document (which itself cites the Motorola → Motorola Mobility → Google Technology Holdings transfers with execution/record dates but no reel/frame). Treat every "Correspondent:" line as unavailable, and do not quote any reel/frame from this report. A verification pull at https://assignment.uspto.gov/patent/index.html (search by patent number 6463534) is required before any of this is used in a litigation or standing analysis.
Inventors
| Inventor | Employer at filing | Basis |
|---|---|---|
| Robert L. Geiger | Motorola, Inc. | Named on the 1999-05-17 assignment of inventors' interest to Motorola, Inc. |
| Jyh-Han Lin | Motorola, Inc. | Same instrument |
| Rajiv Mehta | Motorola, Inc. | Same instrument |
- Per the source document, the first recorded instrument is "ASSIGNMENT OF ASSIGNORS INTEREST" executed 1999-05-17, recorded against the 1999-03-26 filing, assignors MEHTA, RAJIV; GEIGER, ROBERT L.; LIN, JYH-HAN, assignee MOTOROLA, INC. This is the ordinary inventor-to-employer instrument taken ~7 weeks after filing — the hallmark of a corporate R&D filing, not of a portfolio being assembled for sale.
- Unusual-pattern check: not present. There is no evidence any inventor assigned away from Motorola, assigned to a third party, or appears as an assignor on any later instrument. All three inventors appear only once, on the 1999 instrument. No inventor-departure-then-fire-sale pattern is observable. I cannot determine individual inventor tenures beyond this — PEDS/ODP inventor residence data was not retrievable, so "Motorola, Inc." for all three is inferred from the assignment, which is strong but not the same as a payroll record.
Original assignee
Motorola, Inc. (Schaumburg, Illinois) is the assignee named on the issued patent (per the front page and the Google Patents "Assignee: Motorola" field). It is confirmed as the record owner by the 1999-05-17 inventors' assignment.
- Line of business: Consumer and commercial wireless communications — handsets, two-way radio, infrastructure, semiconductors.
- Did it ship a product embodying the claims? Substantially yes, at the platform level. The patent is not directed to a discrete component; it claims a method and system for secure wireless e-commerce in which a network-operator root CA pre-loaded in a wireless client device authenticates third-party "attribute authorities" (claims 1–19, notably claim 1's "root public key certificate pre-loaded in the wireless client device under authority of the wireless network operator" and claim 3's client-certificate payment flow). The corresponding Motorola product is the WAP/WTLS-capable handset platform and its wireless provisioning/OTA software-enablement infrastructure described in FIGS. 1–5 — i.e., an architecture Motorola built into its phones rather than a standalone SKU. No evidence of a separately branded commercial embodiment was found.
- Current status: Operating, but repeatedly restructured — not dissolved and never in bankruptcy. Motorola, Inc. → Motorola Mobility, Inc. (2010 spinoff; Motorola Solutions took the non-mobility business) → acquired by Google Inc. (2011 announced / 2012 closed) → Motorola Mobility LLC sold to Lenovo Group in 2014, while a large block of Motorola Mobility patents, including this one, was retained by Google and parked in Google Technology Holdings LLC. Motorola Mobility LLC (Lenovo) still operates as a handset brand today; the patent's chain diverged from the operating business in 2014.
Assignment timeline
Four recorded events. No reel/frame numbers are available in any source I could reach, and none is quoted below.
1999-05-17 (executed) / recorded 1999-05-17 — Reel not retrieved
- Conveyance: Assignment (Assignment of Assignors' Interest)
- Assignor: Robert L. Geiger; Jyh-Han Lin; Rajiv Mehta (individually)
- Assignee: Motorola, Inc.
- Correspondent: Not retrievable from Assignment Center via available tools. Not captured — no finding.
- Context: Original inventor-to-employer assignment; routine corporate R&D ownership consolidation, not a sale.
2010-12-13 — Reel not retrieved
- Conveyance: Assignment (Assignment of Assignor's Interest)
- Assignor: Motorola, Inc.
- Assignee: Motorola Mobility, Inc.
- Correspondent: Not retrievable. Not captured.
- Context: Internal reorganization — the January 2011 Motorola mobility spinoff; patent follows the handset business into the spun-out entity.
2012-09-18 — Reel not retrieved
- Conveyance: Change of Name (see Google Patents legal events: "MOTOROLA MOBILITY LLC — CHANGE OF NAME (SEE DOCUMENT FOR DETAILS)")
- Assignor: Motorola Mobility, Inc.
- Assignee: Motorola Mobility LLC
- Correspondent: Not retrievable. Not captured.
- Context: Change of name only — no change in beneficial ownership. Recording the Google-era entity conversion (Motorola Mobility, Inc. became an LLC as the Google acquisition closed in May 2012). Do not count this as a transfer in any cascading-transfer analysis.
2014-11-13 — Reel not retrieved
- Conveyance: Assignment (Assignment of Assignors' Interest)
- Assignor: Motorola Mobility LLC
- Assignee: Google Technology Holdings LLC
- Correspondent: Not retrievable. Not captured.
- Context: Internal reorganization / carve-out — the Lenovo sale of Motorola Mobility closed 2014-10-30 and Google retained the Motorola Mobility patent portfolio, parked in its existing Google Technology Holdings LLC IP-holding vehicle. Not a sale to a third-party acquirer of the patent.
Post-issuance record thereafter: Google Patents shows no further reassignment, and the legal status is "Expired – Lifetime," anticipated expiration 2019-03-26 (20 years from the 1999-03-26 filing). The chain terminates at Google Technology Holdings LLC; there is no transfer to any asserter and no transfer to any defensive aggregator.
Family context (for chain-completeness only): priority documents recorded against this family — WO2000059225A1, EP1166557A4, CN1345514A, TW469714B — are all consistent with a single Motorola-originated 1999 filing, with no evidence of separate family-level assignments surfaced.
Timeline diagram
timeline
title Ownership of US 6463534
1999 : Filed by Motorola Inc
: Inventors assign to Motorola Inc
2002 : Patent issued
2010 : Assigned to Motorola Mobility Inc
: Motorola Mobility sues Apple
2012 : Name change to Motorola Mobility LLC
: Second Motorola suit against Apple
2014 : Assigned to Google Technology Holdings LLC
2019 : Patent expires
NPE / troll-pattern signals
1. Shell-entity transfer — not present.
The only post-issuance transfers are Motorola, Inc. → Motorola Mobility, Inc. (2010-12-13), a pure change of name to Motorola Mobility LLC (2012-09-18), and Motorola Mobility LLC → Google Technology Holdings LLC (2014-11-13). Google Technology Holdings LLC carries an "IP/Holdings" suffix, which is a flag only when paired with licensing-only conduct; here it is Google's standard intra-group IP vehicle, the transferor was an operating company whose handset business continued under Lenovo, and there is no evidence of a licensing-only business, no registered-agent address, and no single-member LLC formation tied to this patent. No supporting evidence; do not treat the "Holdings" name alone as a finding.
2. Known asserter in the chain — not present.
No assignee in this chain (Motorola, Inc.; Motorola Mobility, Inc.; Motorola Mobility LLC; Google Technology Holdings LLC) matches any entity on the named lists (Acacia/CombiMatrix, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, Spangenberg entities). No Unified Patents or RPX high-frequency-plaintiff designation surfaced for this patent in the material I could reach.
3. Repeat correspondent across the chain — unclear / no data.
No correspondent of record was retrievable for any of the four events, because the Assignment Center records themselves could not be pulled. This signal cannot be evaluated and must not be reported as either present or not present. If a verification pull at assignment.uspto.gov shows a single correspondent (e.g. a Motorola/Google in-house paralegal or a single outside firm) on all four entries, that would be expected and benign for an intra-group chain of an operating company, not an NPE tell — recurrence only becomes probative when the assignees are unrelated-looking LLCs.
4. Cascading transfers — not present.
Four events across fifteen years (1999, 2010, 2012, 2014), not "multiple consecutive assignments through chained LLCs in <24 months." The 2012 and 2014 events are separated by ~26 months and the 2012 link is a name change, not a transfer. No shared-principal or shared-correspondent-address pattern is evidenced.
5. Pre-litigation transfer — not present (and note the chronology runs the "wrong" way).
The 2010-12-13 Motorola Mobility assignment falls after the filing of Consolidated Case No. 1:10-cv-23580 in S.D. Fla. (filed 2010-10-06, Motorola Mobility, Inc. v. Apple, Inc.) and ~13 months before the second case, 1:12-cv-20271 (filed 2012-01-24). Neither is a transfer within 6 months before a first suit. The 2014 Google transfer postdates all of it. This is the opposite of an arranged pre-suit chain.
6. Bankruptcy fire-sale — not present.
Motorola, Inc. and Motorola Mobility never filed Chapter 7/11. The 2011–2014 events were a spinoff, a strategic acquisition by Google, and a subsequent divestiture to Lenovo — none of which is a bankruptcy sale under §363.
7. Privateering — not present.
No evidence that Google or Motorola transferred this patent to an NPE to assert against competitors. Google retained it in-house and it expired in 2019. (Google's later use of other Motorola patents in counter-assertion contexts is a separate question not supported by anything in this record for the '534 patent.)
8. Defensive aggregator — not present.
The chain terminates at Google Technology Holdings LLC (2014-11-13). No RPX, AST, LOT Network, Unified Patents, or OIN link appears.
Litigation-signal caveat (important, do not overstate): Google Patents asserts "Family has litigation" and links S.D. Fla. cases 1:12-cv-20271 and 1:10-cv-23580 to this family. Both are Motorola Mobility, Inc. v. Apple, Inc. — an operating company asserting against a direct competitor, i.e. the opposite of an NPE posture. However, the complaint text I retrieved for 1:12-cv-20271 enumerates U.S. Patents 6,377,987; 6,008,737; 6,101,531; 6,377,161; and others, and I did not see U.S. 6,463,534 named among them. I therefore cannot confirm that the '534 patent itself was asserted in those cases — only that Google Patents associates the family with them. Verify against the actual complaints/claim charts before relying on this.
Verdict
Operating-company assertion.
Justification: Every recorded link in the chain is intra-group movement inside an operating company — the inventors' 1999-05-17 assignment to Motorola, Inc., the 2010-12-13 Motorola → Motorola Mobility transfer, the 2012-09-18 name change to Motorola Mobility LLC, and the 2014-11-13 transfer to Google Technology Holdings LLC — with no third-party asserter, no shell LLC, no defensive aggregator, and no further assignment before the 2019-03-26 expiry. The only litigation in the family is Motorola Mobility v. Apple (S.D. Fla. 1:10-cv-23580 and 1:12-cv-20271), an operating company suing an actual competitor, which is the antithesis of the NPE pattern; the caveat is that I could not confirm the '534 patent itself is named in that complaint, and no reel/frame or correspondent data was retrievable from USPTO Assignment Center, so this verdict rests on USPTO-derived legal-events data rather than on inspected assignment instruments. This patent is expired and cannot be asserted by anyone today.
Verify at: https://assignment.uspto.gov/patent/index.html (search patent number 6463534) and cross-check https://patents.google.com/patent/[US6463534B1](/patent/US6463534B1)/en legal events; the two should reconcile at four events, none carrying an NPE assignee.
Generated 9/28/2026, 3:33:11 PM
Prior art
Earlier patents, publications, and products that may anticipate or render the claims unpatentable.
I'll research USPTO records and the cited references for US 6,463,534.
Let me try more targeted sources for the patent's citation list.
Let me look for the examiner-cited references (the "Patent Citations" list on the 6463534 face).
Prior-Art Analysis for US 6,463,534 — USPTO Sourcing Result and Reference-Level Review
⚠️ Sourcing status (read this first)
I ran the requested USPTO-targeted searches. Here is exactly what I obtained and what remains unresolved:
What I confirmed
- A USPTO-data mirror (Google Patents,
patents.google.com/patent/US6463534B1/en) exists for the literal number 6463534, matching title, inventors (Geiger; Lin; Mehta), assignee (Motorola, Inc. → Google Technology Holdings LLC), filing/priority 1999-03-26, and grant 2002-10-08. No auto-correction of the number was needed; no similarly-numbered patent was substituted. - USPTO-recorded "Prior art keywords" for this patent: wireless, attribute, certificate, authority, client device — consistent with the claim families recapped in the previously generated sections.
- The patent's own specification contains an applicant-cited "Other Publications" reference list (reproduced verbatim below from the authoritative full text).
What I could NOT retrieve
- The front-page examiner-cited U.S. patent reference block (the "References Cited / U.S. Patent Documents" table with examiner asterisks). Google Patents mirrors this block, but my searches surfaced instead the citation tables of other patents (e.g., US7447784B2, US9008620B2), which list 6463534 as art cited against them — the reverse direction. I did not reach the 6463534 face-page citation table itself before my search budget was exhausted.
- Consequently I will not fabricate an examiner-cited reference list. Each entry below is labeled with its actual evidential basis and confidence.
No-fabrication flag: The reference-by-reference §102 mapping requested cannot be completed at full evidentiary strength because the examiner's cited-patent list was not retrieved. What follows separates (A) references I can confirm from the authoritative text, from (B) candidate patent references that are ambiguous and must not be relied on without PACER/PatentCenter verification.
A. Applicant-cited references (OTHER PUBLICATIONS) — confirmed from the authoritative text
These appear verbatim in the specification's reference list of US 6,463,534. They are "printed publications" and are the only prior-art citations I can state with high confidence as belonging to this patent.
| # | Full citation (as it appears in the patent) | Date | Brief description | Potential §102 relevance to claims |
|---|---|---|---|---|
| A1 | "Wireless Application Protocol Architecture Specification" [WAPARCH], WAP Forum | Apr. 30, 1998 | Defines WAP's transport/security/transaction/session/application layering; the architecture the patent builds on. | Printed publication under pre-AIA §102(a) (publication <1 yr before the 1999-03-26 filing → not §102(b)). Discloses the WAP stack and the client/server/WAP-gateway model permeating claims 1 and 3 and the FIG. 4–5 system. Does not anticipate alone — it teaches the architecture, not the operator-root-CA + attribute-authority certificate-verification + attribute-delivery/payment method. Anticipation fails because no single reference discloses all claimed steps in the claimed arrangement. |
| A2 | Wireless Transport Layer Security [WAPWTLS], WAP Forum | Apr. 30, 1998 | WAP's TLS-equivalent: encrypted channel creation, server authentication via certificate mapping, and optional client key/certificate identification. | §102(a). Directly relevant to the secure-download and client-certificate-presentation limitations (spec's WTLS-encrypted Software Server download; the client→AA "second digital certificate" payment step). Discloses the mechanism (WTLS handshake, cert verification) but not the commerce/billing combination. Single-reference anticipation unlikely; strongest as a §103 secondary reference. |
| A3 | "Wireless Control Message Protocol Specification" [WAPWCMP], WAP Forum | Apr. 30, 1998 | WAP control-message layer (analogous to ICMP). | §102(a). Minimal claim-1/2/3/4 hook — primarily evidentiary context for the WAP embodiment. Not anticipatory. |
| A4 | WAP Identity Module Specification [WIM], WAP Forum | Mar. 12, 1999 | Defines the WIM: tamper-resistant storage/interface for keys and certificates in the WAP security layer. | Critical timing: only 14 days before the 1999-03-26 filing. §102(a) only (clearly not §102(b)). Bears directly on the dependent-claim limitations recapped earlier — pre-loading the client certificate into a WIM/SIM 452 and storing domain root keys (spec: "client keys are preferably issued and stored in the WIM"). A close reference for those dependent claims, but its sub-one-year status and the invention-date/inuring questions make it a fragile §102(a) pin — and it does not reach the operator-CA/attribute-authority commerce claims. |
| A5 | Draft American National Standard X9.68-199x: Digital Certificates for Mobile, Account Based and High Transaction Volume Financial Systems, American Bankers Association | ~199x (draft; the spec also cites a Mar. 1, 1999 [X968] version) | Standard for digital certificates in mobile/account-based/high-volume financial systems — including the validation-service concept the patent leans on. | §102(a). The patent expressly derives its certificate and validation-server teaching from X9.68 ("a validation service is defined in X9.68"). Relevant to the AA-certificate and validation-server claim elements; does not anticipate the wireless-operator-domain commerce method as a whole. |
| A6 | "Standard Specifications For Public Key Cryptography", IEEE P1363/D1a (Draft Version 1a) [P1363] | Feb. 1998 | Public-key cryptography standards (signatures, key agreement, encipherment). | §102(a). Generic crypto-primitive reference; supplies the RSA/EC primitives the claims presuppose. Not anticipatory of any claim as a whole. |
| A7 | PKCS #1: RSA Encryption Standard, version 1.5 [PKCS1], RSA Laboratories | Nov. 1993 | RSA encryption/signature encoding standard. | §102(b) (published >1 yr before filing). Generic primitive; not anticipatory. |
| A8 | PKCS #15: Cryptographic Token Information Standard [PKCS15], working draft version 1.0, RSA Laboratories | Nov. 1998 | Token/object formats for cryptographic tokens (used by the patent's WIM: "The WIM uses PKCS15 for object formats"). | §102(a). Relevant to the WIM/token dependent claims; not anticipatory. |
| A9 | http://www.wapforum.org/ (URL citation) | — | Location of the WAP specifications. | Not itself a prior-art reference; a pointer. |
Net §102 assessment for Section A: Every confirmable reference is either (i) an architectural/standards document that supplies elements but not the claimed combination, or (ii) a crypto-primitive standard. None of A1–A9 anticipates any independent claim under §102 alone. Their realistic role is (a) evidence that the WAP/WIM/X9.68 framework was known, feeding a §103 obviousness theory, and (b) §102(a) art against the narrowest dependent claims (WIM/SIM storage; PKCS#15 object formats; expiry of attribute certificates).
B. Candidate U.S. patent references — ⚠️ AMBIGUOUS, DO NOT RELY WITHOUT VERIFICATION
My searches returned the following U.S. patents inside a Google Patents citation table that also happened to contain US6463534B1 — but the table belongs to the citing patent (US7447784B2, "Authentication method using cellular phone in internet"), not necessarily to 6463534's own face. I therefore cannot confirm they are cited by 6463534:
| Candidate | Title / Assignee | Dates | Description | Status |
|---|---|---|---|---|
| US 5,608,778 A | Cellular telephone as an authenticated discount card — Lucent Technologies Inc. | filed 1994-09-22; issued 1997-03-04 | Uses a cellular phone as an authenticated instrument (discount card) — conceptually near the patent's "electronic voucher" and phone-as-token ideas. | Unconfirmed as 6463534 art. If actually on the 6463534 face, it would be §102(b) art (issued >1 yr before filing) relevant to the voucher claims (claim family 2). |
| US 5,991,749 A | Method and apparatus for performing financial transactions using a mobile communication unit — Morrill, Jr. | filed 1996-09-11; issued 1999-11-23 | Mobile-unit financial transaction system (payment via wireless device). | Unconfirmed. Issued ~8 months after the 1999-03-26 filing, so it could only be art via its 1996 filing date under pre-AIA §102(e) — and only if it is in fact cited on 6463534. Relevant to the payment step of claim family 1. |
Interpretation caution: These two patents are very likely the art cited against US7447784B2, not against 6463534. Presenting them as 6463534's cited references would violate the no-fabrication rule. Treat them as leads to check, not findings.
I found no evidence of any examiner-cited foreign patent document (WO/EP/JP) on the 6463534 face; the family members (WO2000059225A1, EP1166557, CN1345514, TW469714B) are the patent's own family, not prior art.
C. What "most relevant prior art" looks like — analytical summary (clearly labeled as analysis, not a legal conclusion)
Given the confirmed reference set and the claim families from the earlier sections, the best-supported posture is:
- Closest art overall: the WAP security stack documents (A1 + A2 + A4) read together. WAPWTLS (A2) supplies the certificate-verified encrypted channel and server/client authentication; WIM (A4) supplies secure on-device key/certificate storage. This combination is the strongest §103 attack surface against the broadest method/system claims (claim families 1, 3, 4).
- Closest single reference for the "voucher" claims (family 2): is not among the confirmed references. If US 5,608,778 A is genuinely on the face, it becomes the leading §102(b) candidate for the voucher concept — but that is unverified.
- Closest art for the billing-on-telephone-bill limitation: not identified in the confirmed set; the patent's step "AA instructs billing computer 402 to add the fee to the customer's bill" may have no cited counter-reference, which is itself worth noting.
- The operator-root-CA → dependent-attribute-authority verification architecture (the core of claim family 1) does not appear anticipated by any single confirmed reference; the standards documents describe domains/validation generically but not this specific operator-rooted merchant-attribution model.
Bottom line: On the evidence I could actually retrieve, no confirmed reference anticipates the independent claims under §102; the confirmable art is §102(a)/(b) background material best deployed for §103 and against narrow dependent claims. The only potential §102 candidates are the two unverified U.S. patents in Section B.
D. Recommended verification steps (to complete the requested per-reference mapping)
- Pull the 6463534 front page directly — USPTO PatentCenter (application 09/276,978) or the granted-PDF "References Cited" block — to obtain the definitive examiner-cited U.S. patent list and confirm whether US 5,608,778 A / US 5,991,749 A are on it.
- Confirm each reference's §102 subsection using its actual publication/issue date versus the 1999-03-26 filing/priority date (pre-AIA §102(a) for art <1 yr; §102(b) for art >1 yr; §102(e) for U.S. filings/patents).
- Cross-check the EP1166557 prosecution file (EPO Register) and WO2000059225 ISR for the search-examiner's cited art — often broader than the U.S. face and a fast route to the true closest prior art.
- Map confirmed references to the verbatim granted claims (which were not in the excerpt I was given) rather than to my paraphrase, since anticipation must be element-by-element on the actual claim language.
Confidence disclosure: Section A entries — high confidence (verbatim from the authoritative text). Section B entries — low confidence / unverified. The §102/§103 characterizations in Sections A and C are my analytical assessment, not a legal opinion, and depend on the exact granted claim language I was unable to obtain.
Generated 9/28/2026, 3:33:24 PM
Obviousness
Combinations of prior art that suggest the claimed invention would have been obvious under 35 U.S.C. § 103.
I'll first try to retrieve the actual cited prior art for this patent, since the authoritative excerpt I was given contains only "Prior art keywords" and a prior-art date — not the Patent Citations / Cited-By list.
The results gave me another patent's citation list. Let me target US6463534's own front-page references directly.
Let me try Justia and the Google Patents citation block directly.
Obviousness Analysis — U.S. Patent 6,463,534 Under 35 U.S.C. § 103
0. Sourcing preamble (read before the analysis)
Important limitation. The authoritative Google Patents rendering I was given for US6463534B1 does not contain a populated "Patent Citations" / "Cited Prior Art" list. What that page does give me under its prior-art heading is:
- Prior art keywords:
wireless,attribute,certificate,authority,client device - Prior art date: 1999-03-26 (identical to the filing date — i.e., no earlier foreign priority)
So "the Prior Art section of this page" is thin. I supplemented it with searches and recovered a partial front-page reference list from the Justia rendering of the same patent (https://patents.justia.com/patent/6463534), plus applicant-admitted prior art that appears in the specification body itself. I was not able to retrieve the complete reference list (U.S., foreign, and NPL) for this patent. Everything below is built only on what I could actually see, and every characterization of a reference's disclosure content is flagged.
Two things that are NOT prior art and should not be used as such: the Google Patents "Cited By (234)" list (those are later documents citing '534 — they are evidence of nothing more than the patent's citation footprint), and the family/related-record citations surfaced in other patents' front pages (e.g., the reference list of US7447784B2, which cites '534; those references belong to a different patent's record).
Note on my own sections: this analysis inherits, and does not disturb, the uncertainty flags in the earlier Claim summary section — the literal granted claim language was not in the excerpt I was given. Accordingly, the analysis below is done at claim-element granularity (using the reconstructed independent claims 1–4 from the Summary/Description), not at verbatim-claim-limitation granularity. If the granted claims contain limitations not restated in the Summary, this analysis must be re-run against the real text.
Minor housekeeping: my instructions carry two different "current dates" (2026-04-26 in the task line, 2026-09-28 in the system line). Neither affects the substance below, but I flag it rather than silently harmonize.
1. The prior-art record I could actually reconstruct
1(a) U.S. patents in the "Referenced Cited" list (partial — 8 of an unknown total)
From the Justia rendering of '534:
| Patent | Issue date | Inventor (as listed) | In-record note |
|---|---|---|---|
| US 5,659,616 | 1997-08-19 | Sudia | Pre-filing — facially §102(a)/(b) art |
| US 5,671,279 | 1997-09-23 | Elgamal | Pre-filing |
| US 5,712,914 | 1998-01-27 | Aucsmith et al. | Pre-filing |
| US 5,796,841 | 1998-08-18 | Cordery et al. | Pre-filing |
| US 5,878,144 | 1999-03-02 | Aucsmith et al. | Pre-filing (24 days prior) |
| US 5,884,158 | 1999-03-16 | Ryan, Jr. et al. | Pre-filing (10 days prior) |
| US 5,903,878 | 1999-05-11 | Talati et al. | Post-filing — see caveat below |
| US 5,987,440 | 1999-11-16 | O'Neil et al. | Post-filing — see caveat below |
⚠️ Caveat with real §103 consequences. US 5,903,878 and US 5,987,440 issued after the 1999-03-26 filing date. Under pre-AIA law (which governs here — the application was filed 1999-03-26, well before the AIA's 2013 first-inventor-to-file change), a reference with a post-filing issue date cannot be §102(a) or §102(b) art on its face. It can only qualify as §102(e) art if its own application filing date precedes the '534 invention/filing date, or via some other earlier publication. A §103 combination built on either of these two without first establishing a §102(e)-qualifying filing date is legally defective. This is exactly the kind of gap that decides an invalidity case.
⚠️ Content caveat. I could not verify the disclosure content of any of these eight references in this session. My prior familiarity suggests several are certificate-based commercial-transaction / secure-electronic-commerce references in the same neighborhood as the '534 disclosure, but I am not asserting specific teachings, columns, or claim mappings for them — that requires the actual documents.
1(b) Applicant-admitted prior art (AAPA) — the strongest and most reliable part of the record
These are named in the '534 specification itself and characterized by the applicants as the state of the art they were building on. Applicant-admitted prior art is squarely usable in a §103 analysis:
| Reference | Date (as given in the patent) | Why it matters to '534 |
|---|---|---|
| WAP Architecture Specification [WAPARCH], WAP Forum | 1998-04-30 | Discloses the layered WAP stack (transport, security, transaction, session, application) that '534 says it builds on |
| Wireless Transport Layer Security [WAPWTLS], WAP Forum | 1998-04-30 | Discloses WTLS, including the patent's own description of the security levels: anonymous key exchange → server authentication via a certificate "mapping back to an entity trusted by the client" → full client private key + public key certificate for client authentication |
| WAP Identity Module Specification [WIM], WAP Forum | 1999-03-12 | Discloses the WIM and PKCS#15 object formats — i.e., the secure token '534 uses to hold keys/certificates |
| X9.68-199x draft, Digital Certificates for Mobile, Account Based and High Transaction Volume Financial Systems (ANSI draft; cited as Mar. 1, 1999) | 1999 | The patent's own citation for "a description of digital certificates"; the title itself targets mobile, account-based, high-transaction-volume certificate systems |
| IEEE P1363/D1a, Standard Specifications for Public Key Cryptography | 1998-02 | Standard public-key cryptography (signature/key agreement/encipherment) |
| PKCS #1 v1.5, RSA Encryption Standard | 1993-11 | RSA encryption standard |
| PKCS #15, Cryptographic Token Information Standard, working draft v1.0 | 1998-11 | Token object formats (used by WIM) |
Why this matters more than the U.S. patent list: the '534 specification repeatedly characterizes its own building blocks as conventional — e.g., "Certificates are the cornerstone of the secure electronic commerce system and a description of digital certificates can be found in Draft American National Standard X9.68-199x"; "Every device … has one or more certificates. They all have a trusted root certificate…"; and on the voucher embodiment, "This latter scheme is particularly simple to implement using the already described public key certificate common to all the members of the domain." Those are admissions of routine implementation.
1(c) General-knowledge art I am confident about (and would cite)
- ITU-T X.509 (1997) / IETF RFC 2459, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile" (Jan. 1999) — I am moderately-to-highly confident these define the standard certificate hierarchy (a root CA certifying subordinate/CA certificates, i.e., "a digital certificate that is dependent from the root public key certificate") and the attribute certificate construct. Verify the RFC 2459 publication date and the attribute-certificate coverage before relying on it.
- Menezes, van Oorschot & Vanstone, Handbook of Applied Cryptography, CRC Press (1997) — standard hierarchical PKI trust-model practice. Notably, this very handbook is cited as prior art in the record of US 8,468,354 (a different patent), which is corroboration that it was the ordinary reference work in this field at the time — but it is not confirmed to be in the '534 record.
2. Level of ordinary skill in the art (POSITA)
For a 1999 priority date, a POSITA would be a person with a bachelor's degree in electrical engineering or computer science plus ~2–4 years of experience in wireless data services and/or applied cryptography/PKI, or equivalent. Critically, this POSITA would be simultaneously conversant with (i) the WAP Forum specifications then being finalized, (ii) X.509/X9.68-style certificate practice, and (iii) wireless carrier billing/OSS. This is a narrow, standards-driven, actively-crowded art — the KSR "predictable variation" factors apply with unusual force here because the applicants were, by their own description, implementing published standards.
3. Legal framework
Pre-AIA §103(a): would the claimed subject matter as a whole have been obvious at the time of invention to a POSITA? Under KSR Int'l v. Teleflex, 550 U.S. 398 (2007), the following rationales are available and are the ones I apply below:
- Combining prior-art elements according to known methods to yield predictable results.
- Simple substitution of one known element for another.
- Use of a known technique to improve similar devices in the same way.
- Applying a known technique to a known device ready for improvement to yield a predictable result.
- "Obvious to try" — a finite number of identified, predictable solutions.
- Design incentives / market pressure, including the "design need or market pressure to solve a problem" and "the desire to apply a known technique to a known device."
4. Element-by-element obviousness analysis
Ground 1 — Primary: the core "AA certificate dependent from the operator root" method claim (independent claim 1; also grounds the apparatus claim 3)
| Claim element (reconstructed) | Candidate prior art | Reasoning |
|---|---|---|
| System has a wireless network operator CA with a root public key certificate | X9.68 draft; X.509/RFC 2459 hierarchy; AAPA: "Every device … has a trusted root certificate which is the Public Key Certificate of the CA" | Root-CA hierarchy is the definition of standard PKI. Not a point of novelty. |
| At least one attribute authority with a digital certificate dependent from the root | X.509/RFC 2459 subordinate-CA/attribute-certificate constructs; X9.68 (mobile/account-based certificates) | "Dependent from the root" is simply the parent-child certificate chaining that these standards specify. |
| AA reachable by the wireless client over the wireless network | WAPARCH + WTLS (server authentication "mapping back to an entity trusted by the client") | The WAP spec already teaches a network-reachable server proving identity to a wireless client via a certificate. |
| Root certificate pre-loaded in the client under authority of the wireless network operator | WIM Specification (Mar. 12, 1999) + PKCS#15; AAPA: personalization/enrollment sections | Pre-provisioning a root cert into the device's WIM/SIM at personalization is the standard bootstrap the '534 specification itself describes as routine. |
| Verify the AA at the client using the AA cert + pre-loaded root | WTLS class-1/class-2 authentication as described in the patent; X.509 path validation | Verification of a chained certificate against a locally stored root is textbook. |
| Deliver an attribute over the wireless network and enable it at the client | WAPARCH/WTLS content delivery; the cited U.S. commerce patents (Sudia '616, Elgamal '279, Aucsmith '914/'144, Talati '878) — content unverified | Delivering data over the wireless bearer and then executing/unlocking it is the ordinary function of a WAP-capable handset with cryptographic APIs (the '534 "overall security model" paragraph describes exactly this stack as pre-existing). |
Motivation to combine (Ground 1). All of these are drawn from the same standards effort and the same problem space — the WAP Forum documents were being issued as a coherent, deliberately interoperable stack (that is their stated purpose), and X9.68's own title targets mobile, account-based certificate systems. A POSITA confronted with the recognized problem — "how do I let third parties sell content to subscribers without building a new billing/identity infrastructure per merchant?" — had a finite, enumerated set of known solutions (hierarchical PKI under a carrier root + WAP transport security). Under KSR rationales 1, 3, 5 and 6, that is a textbook obviousness posture.
Confidence: medium-high that claim 1 would be held obvious if the cited U.S. references actually disclose wireless content delivery/enablement. Low if they are all wireline/desktop commerce references — in which case one needs a wireless-specific delivery reference from the record's NPL side (WAP/WTLS), which the applicants themselves supplied.
Ground 2 — Payment via a second (client) digital certificate verified against the root, plus carrier billing
| Element | Candidate prior art | Reasoning |
|---|---|---|
| Client delivers its own certificate to the AA; AA verifies it against the CA root | WAP WTLS class 2 ("server and client authentication," as explicitly described in the '534 text); X.509 client certificates; Sudia '616 / Talati '878 (commerce-over-network with certificates; content unverified) | Mutual authentication from a shared root is the defining WTLS class-2 behavior. The patent's own words are that the client "delivers a certificate to the AA that is certified within the wireless service provider domain." |
| Instruction to the operator's billing computer to add the fee to the subscriber's wireless bill | Pre-existing wireless carrier billing systems; art in adjacent Motorola/related records such as US 5,608,778 (cellular telephone as authenticated transaction controller), US 5,864,610 (telephone billing system for data services), and WO 97/45814 (Vazvan, real-time remote payments) — ⚠️ these were surfaced in a different patent's citation list (US 7,447,784), not verified in the '534 record | Billing content/services onto the subscriber's existing carrier invoice is the classic design-incentive/market-pressure case (KSR rationale 6): the carrier already has the billing relationship; the patent itself sells this as a convenience feature, not a technical achievement. |
Motivation. Once the carrier is the PKI root and the transport is WAP/WTLS, routing charges to the carrier's billing system exploits an infrastructure that already exists — a predictable, economically motivated integration ("greater ease of … revenue collection," per the '534 background — the patent names this as the goal, which is itself a strong motivation statement attributable to the applicant).
Confidence: medium. The billing-integration element is the one most likely to survive a naive challenge only because a defendant must produce a wireless-billing reference; such references plainly existed pre-1999 (carrier billing of valued-added services), and the ones I found in the neighbouring record suggest a short, findable list.
Ground 3 — The electronic voucher between first and second attribute authorities (independent claim 2)
| Element | Candidate prior art | Reasoning |
|---|---|---|
| First AA delivers a first attribute; a voucher is generated verifiable by a second AA | Coupon / loyalty-point / promotional-credit art (pre-1999 loyalty and prepaid-credit systems are legion); PKI-verifiable token art | Cross-merchant promotional credit is an old commercial practice; wrapping it in a signed token is a substitution of a known medium. |
| Voucher delivered AA-to-AA via a connection or via the wireless client | WAP/WTLS bearer; general network messaging | Two alternative transports of the same payload — KSR rationale 2 (simple substitution). |
| Second AA identifies/verifies the voucher and delivers the second attribute | The patent's own admission | The specification states the client-carried voucher scheme "is particularly simple to implement using the already described public key certificate common to all the members of the domain" — i.e., the patent concedes that verification is routine once the shared domain root exists. |
Motivation. Within a single cross-certified domain, the domain root gives every member a common verification anchor; the specification says so outright. Under KSR, an applicant's own statement that an implementation is "simple to implement" using already-described components is powerful evidence of obviousness of that implementation. The commercial motivation (cross-merchant promotion increases traffic for both merchants) is a pure business design incentive.
Confidence: medium-high — this is, in my view, the most vulnerable independent claim in the patent because the only arguably inventive element (a trusted cross-merchant credit token) is explicitly described in the specification as a routine application of the domain PKI.
Ground 4 — The record-keeping / license-enablement / version-rule claims (independent claim 4 and dependents)
| Element | Candidate prior art | Reasoning |
|---|---|---|
| Maintain content certificates and license certificates on a server; per-client record of licenses and associated content items | Electronic software distribution & license-management art (e.g., Fawcett-type "identifying and obtaining computer software from a remote computer" references — not verified in the '534 record); X9.68 attribute certificates | Server-side asset/license registries were standard practice in software distribution and enterprise asset management. |
| Server keeps the association between client ID and licenses, and the association can be swapped to a new device ID (repair/replacement scenario) | Ordinary database/administrative practice; certificate revocation lists (X.509/CRL) | Re-pointing a database foreign key from one device serial to another, then re-issuing licenses and CRL-ing the old ones, is administrative bookkeeping, not a technical advance. KSR rationale 4 applies squarely. |
| License verified if the content name is pre-associated, or if the name satisfies a predefined rule (e.g., "Browser 1.x permits all future versions between 1.0 and 2.0") | Version-range licensing / upgrade-eligibility rules in software distribution | The patent presents version-range eligibility as an arbitrary design choice ("This association may be in the form of a look-up list … or a predefined rule"). Under KSR, a recitation of a result to be achieved via a conventional data structure (a name list or a version range) with no disclosed technical improvement is not inventive. |
| "Means for enabling the attribute" / "sending means" / "receiving means" (apparatus claim 3) | Any radio transceiver + processor executing code | Under §112 ¶6-style construction these are generic structural recitations; a general-purpose processor with ROM (which the '534 specification itself requires) is the standard implementation. |
Motivation. The whole point of these claims is fleet/asset administration — a recognized need, addressed by known database and licensing techniques, with predictable results.
Confidence: medium-high on the record-keeping/version-rule dependents; medium on the replication-between-devices aspect. The §103 exposure here is really §103 via rationale 4 and the "printed matter"/data-structure-is-conventional line of reasoning.
5. Where the obviousness case is weakest (patentee's counterarguments to anticipate)
Being honest about the strength of the case matters as much as the mapping:
- The "wireless network operator as the PKI root, with third-party merchants as subordinate attribute authorities" architecture. If a defendant cannot produce pre-1999 art showing a carrier-rooted PKI in which third-party content merchants hold dependent certificates, the patentee will argue the specific trust topology — carrier as root, merchants as AA — was a deliberate and non-obvious design choice (as opposed to the more common model of independent merchant CAs or a browser-vendor root store). This is the patent's best non-obviousness argument and the point on which a real invalidity contention would likely turn. The counter is the WAP-Forum's own multi-domain/cross-certification work and the X9.68 "account-based" scope — but I have not verified that the cited WAP documents teach a carrier-rooted merchant hierarchy.
- Pre-loading the root "under authority of the wireless network operator" — the patentee will argue this provisioning relationship was novel. Counter: the patent's own "System bootstrap" paragraph describes loading domain root certificates onto a card before issuance as standard, including manufacturer-rooted provisioning of service provider root certificates.
- Post-filing dates on two of the eight references (US 5,903,878; US 5,987,440) — a defendant relying on them must first establish §102(e)-qualifying filing dates, or the combination collapses.
- Secondary considerations. I found no evidence in the record bearing on commercial success, long-felt need, failure of others, copying, or industry praise for this specific patent. Absent a nexus between any such evidence and the claims, it does not rebut a prima facie case — but I cannot rule it out, and the patentee's licensing history (the family shows litigation) is typically inadmissible or weak as a secondary consideration without more.
- Reference content is unverified. Every U.S. reference characterization above beyond its number/date/inventor is flagged. A genuine §103 contention requires a limitation-by-limitation claim chart with pin cites. I have deliberately not manufactured those pin cites.
6. Verification checklist before this analysis could be used for anything
- Pull the granted claims (USPTO PatentCenter, appl. 09/276,978) — confirm claim numbering and verbatim language; re-run this analysis against the real text.
- Pull the complete IDS/1449 and PTO-892 (references cited and considered) from the file wrapper — the Justia list I recovered is partial (8 of an unknown total) and may not include examiner citations or foreign/NPL items.
- Obtain the full text of the eight "Referenced Cited" U.S. patents and confirm (a) invention/publication dates and (b) actual disclosure, with column/line cites.
- Confirm the §102(e) filing dates for US 5,903,878 and US 5,987,440, or drop them.
- Confirm the X9.68 draft's actual publication date and content (the patent cites it as "X9.68-199x"; the ANSI draft date listed in the reference block is Mar. 1, 1999 — 14 days before the filing date, so its status as a §102(a)/(b) printed publication requires care).
- Confirm RFC 2459 (Jan. 1999) and ITU-T X.509 (1997) coverage of attribute certificates and subordinate-CA chaining.
- Only then build the claim charts and the motivation-to-combine narrative with exhibits.
7. Confidence summary
| Conclusion | Confidence |
|---|---|
| The '534 specification admits the WAP/WTLS/X9.68/PKCS/WIM framework as pre-existing (AAPA) | High — directly quoted from the authoritative text |
| Claim 1 (AA-verification + attribute delivery method) would be prima facie obvious over WAP/WTLS + hierarchical PKI + a wireless commerce/delivery reference | Medium-high, conditioned on reference content |
| Claim 2 (AA-to-AA electronic voucher) is the most vulnerable independent claim | Medium-high — supported by the applicant's own "simple to implement" admission |
| Claim 3 (apparatus) falls with claim 1 plus generic hardware | Medium-high |
| Claim 4 and its record-keeping/version-rule dependents are obvious as administrative/data-structure design choices | Medium-high |
| Carrier-rooted, merchant-subordinate trust topology was obvious in 1999 | Medium/uncertain — this is the pivot point, and I lack verified art on it |
| Any specific reference discloses a specific claimed element | Low/unverified — no pin cites fabricated |
| The complete prior-art list for '534 | Not obtained |
Bottom line. On the record I can actually see, US 6,463,534 presents a moderate §103 risk, driven less by any single anticipatory reference and more by the applicants' own specification, which frames the invention as the integration of then-published WAP/WTLS standards with then-standard hierarchical PKI and ordinary carrier billing. The strongest grounds are: (i) WAP/WTLS + X9.68/X.509 + a wireless commerce reference against claims 1 and 3; and (ii) the applicant's explicit "simple to implement" admission against the voucher claim 2. The strongest defense is the specific topology — carrier as PKI root with third-party merchants as dependent attribute authorities — which requires art I could not verify and which a POSITA-at-the-time argument would need to address head-on.
Generated 9/28/2026, 3:34:11 PM
Extensions
Patent term adjustments, term extensions, continuations, divisionals, family members, and expiration dates.
Derivative works
Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.
Keep exploring
Other patents in Wireless Technologies
- US 6973334I'll verify the patent details and check for any 2026 CAFC docket activity. US Patent 6,973,334 — Verification Summary Data source: Full patent text (Google Patents / USPTO), cross-checked against search results. Where the record is…
- US 10212586I'll verify the patent details against live sources, including any 2026 Federal Circuit activity. Let me check for any 2026 appellate activity specifically involving this patent, and the disposition of the district court case. US…
- US 6928306I'll search for litigation/docket information on this patent while grounding the summary in the authoritative patent text provided. Let me search specifically for the CAFC appeal and the IPR proceeding mentioned in the results. Let me do a…
- US 6430498I'll search for authoritative information on this patent number and its litigation history. US 6,430,498 — "Portable terminal with the function of walking navigation" Scope note first, per your instructions: I searched public web sources…
- US 6580999I'll verify this patent against live sources, particularly for any 2026 CAFC activity. Let me check the Federal Circuit appeals and 2026 docket activity more specifically. Identification of the record I searched for the exact patent number…
- US 6408193I'll run targeted searches for this patent number and its current litigation status. Let me check the Federal Circuit appeal history and any 2026 activity for this patent. One more check on whether the '193 patent itself is in any pending…
- US 8023580I'll run targeted searches for this specific patent number and check current docket/litigation status. Let me check for any 2026 CAFC docket activity and the reexamination certificate status. Let me make one more focused attempt at finding…
- US 7340612I'll search for authoritative information on this patent, including any 2026 CAFC activity. Let me run a couple more targeted searches to check for litigation or appellate activity before summarizing. US Patent 7,340,612 — Summary…
This patent in court (2)
2 tracked lawsuits name US 6463534.