Invalidity dossier

US 9189787

Method and apparatus for conducting e-commence and m-commence

Current assignee: RFCyber Corp.

Added 9/25/2026, 9:22:52 PM

At a glanceNo PTAB challenges8 lawsuits on fileasserted by RFCyber Corp.Financial Technology (FT)

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.

✓ Generated

I'll verify the patent record and check for any current litigation activity, including CAFC dockets.

Let me check for more recent 2026 appellate docket activity and the IPR outcome details.

US Patent 9,189,787 — Analyst Summary

Verification note on identifiers

I searched for the exact number 9189787. All authoritative hits (Google Patents, the patent's own front page reproduced in PTAB and district-court filings, and the PTAB FWD) resolve to US 9,189,787 B1. I did not substitute results for similar-looking numbers (e.g., 9,189,777 or 9,187,987). Note that the official title contains the typographical spellings "E-COMMENCE" and "M-COMMENCE" (not "e-commerce"/"m-commerce"). Per your instruction I reproduce them literally and do not auto-correct.


Bibliographic data

Field Value
Patent number US 9,189,787 B1
Title Method and apparatus for conducting e-commence and m-commence
Application no. 13/903,420
Filing date May 28, 2013
Issue / date of patent Nov. 17, 2015
Inventors Liang Seng Koh (Fremont, CA); Futong Cho (Milpitas, CA); Hsin Pan (Fremont, CA); Fuliang Cho (San Jose, CA)
Assignees Rich House Global Technology Ltd. (Shenzhen, CN); RFCyber Corp. (Fremont, CA)
Effective priority Sept. 24, 2006 (via continuation chain)
Continuation of 13/400,038 (filed Feb. 18, 2012, now US 8,448,855), which is a continuation of 11/534,653 (filed Sept. 24, 2006, now US 8,118,218)
Claims 19 (2 independent: claim 1 device, claim 11 method)
Primary examiner Christopher Stanford
Adjusted expiration Oct. 18, 2026 (Google Patents legal-status field)
CPC G06Q 20/3672; G06Q 20/00; G06Q 20/36

Source: https://patents.google.com/patent/US9189787/en

Minor discrepancy flagged: the Unified Patents profile for this patent lists priority 2006‑09‑23, application date 2013‑05‑27, grant date 2015‑11‑16 and expiration 2026‑10‑17 — a one-day offset from the Google Patents/USPTO front-page values above (likely a time-zone/derived-date artifact). I report the front-page values as authoritative and note the discrepancy rather than silently harmonizing it.


Abstract (verbatim)

"Techniques for funding an electronic purse (e-purse) are disclosed. According to one aspect of the invention, a mechanism is provided to enable a portable device to conduct transactions over an open network with a payment server without compromising security. In one embodiment, a device is loaded with an e-purse manager. The e-purse manager is configured to manage various transactions and functions as a mechanism to access an e-purse therein. The e-purse is funded by interactions among the e-purse manager, a payment server and a financial institution (its server) that maintains an account therefor."

(Note: the abstract describes funding an e-purse, which is the subject matter of the parent '855 patent; the '787 specification reuses that abstract even though its claims are directed to the dual-interface device/method.)


Plain-language overview of the independent claims

Claim 1 — Portable device for commerce (apparatus)

A mobile device (e.g., an NFC phone) that contains, in a smart card module:

  1. An emulator — stores security values and updated transaction logs (the "single functional card" data structure, e.g., MIFARE).
  2. An e-purse applet — makes the device act as an electronic purse.
  3. Both already personalized — a personalization process built on a first security channel leaves the emulator holding a set of keys for later data-access authentication, and configures the applet to transact with a network server over a second security channel.
  4. A first interface for near-field/field communication (NFC) with a reader — enables electronic commerce against funds in the emulator.
  5. A second interface for mobile commerce with a payment server via an application — likewise against funds in the emulator.
  6. A purse manager midlet running on the device — acts as an agent brokering communication between the e-purse applet and the payment server.

In short: one portable device with a pre-personalized emulator + e-purse applet, two separate transaction channels (contactless/e-commerce and network/m-commerce), and a midlet agent tying the applet to the server.

Claim 11 — Method for a portable device for commerce

The method counterpart, reciting the same elements as steps:

  1. Loading a smart card module with the emulator (security values + transaction logs) and the e-purse applet.
  2. Personalizing the emulator and applet via a personalization process built on a first security channel, so that the emulator stores keys for later access authentication and the applet is configured to transact with a network server over a second security channel.
  3. Performing NFC through a first interface with a reader to carry out e-commerce.
  4. Performing mobile commerce through a second interface with a payment server, the application running on the device acting as agent between applet and server.

The dependent claims add: a security module that installs/personalizes the applet via either interface, with keys updated at personalization completion (2, 12); the Global Platform / MIFARE "transformed password" limitation (3, 13); RFID-based first interface allowing the device to act as a tag (4, 14); a web agent on a computing device composing network requests (5, 15); the layered "initial security channel then security channel on top" architecture (6, 16); the personalized data set of operation keys, default PINs, administration keys and passwords (7, 17); and the smart card module being internal to or externally inserted into the device (8–9, 18–19).


Post-grant and litigation status

PTAB (all naming this patent):

  • IPR2021-00955 (Google LLC / Google Payment Corp.) — terminated Oct. 20, 2021 (settlement).
  • IPR2021-00980 (Samsung) — terminated April 11, 2022 (settlement).
  • IPR2022-00412 ([Apple Inc.](/litigations/by-plaintiff/Apple%20Inc.)) — petition Jan. 14, 2022; Final Written Decision July 18, 2023 holding no challenged claims (1–19) unpatentable*; RFCyber prevailed. An IPR certificate was entered effective March 29, 2024.

District court dockets listing the '787 patent (per Unified Patents family/litigation data and RFCyber's mandatory notices): E.D. Tex. 2:20-cv-00274 (Google), 2:20-cv-00335 (Samsung), 2:20-cv-00336 (LG), 2:24-cv-00576 (Volkswagen, involving Plug&Charge/Electrify America functionality); W.D. Tex. 6:21-cv-00916 (Apple), 6:22-cv-00697 (Visa), 6:23-cv-00708, 1:23-cv-00661.

Federal Circuit:

  • Appeal 2023-2396 — dismissed Feb. 21, 2024, after a deconsolidation order; Apple withdrew from the companion Appeal 2023-2418, whose caption was revised to reflect Apple's non-participation (order reported as a PACER docket entry; see the PatSnap litigation write-up summarizing Case 23-2396). That order expressly made no finding on validity.

On your specific request re: "CAFC 2026 dockets for 9189787": I did not locate any 2026 Federal Circuit docket that directly adjudicates US 9,189,787. The 2025–2026 RFCyber appellate decisions I found concern different patents in the same family portfolio — 24-1612 (Rule 36 affirmance re US 10,600,046) and 24-1614 / RFCyber Corp. v. Squires, decided Dec. 17, 2025 (affirming unpatentability of US 11,018,724) — not the '787. I flag this explicitly rather than infer a '787 docket. If a 2026 docket exists, it is not surfacing in public search indexes I can reach; I cannot confirm it with high confidence.


Confidence and caveats

  • High confidence on bibliographic fields, claim text, abstract, and the IPR2022-00412 outcome (grounded in the patent's own front page and the PTAB Final Written Decision).
  • Moderate confidence on the exact current (April 2026) procedural posture of every co-pending district-court and appellate matter; dockets change and some related suits (e.g., the LG 2:20-cv-00336 case) were dismissed with prejudice (per an AO-120 report, Sept. 15, 2021). Verify against USPTO PatentCenter and PACER before relying on any single docket's status.
  • The abstract/claims describe the e-purse/funding subject matter shared with the parent patents; this is a continuation, so its claims are entitled to the Sept. 24, 2006 priority date via the 13/400,038 → 11/534,653 chain.

Generated 9/25/2026, 9:23:19 PM

Cases on file (8)

Group view →

Specific litigation cases in our database that name US patent 9189787. The free-form analysis below may also discuss cases beyond this list.

Lawsuits filed per year

2020: 3 cases3'202021: 1 case'212022: 1 case'22'232024: 1 case'24
Cases asserting US 9189787, by filing year.

Litigation summary

Past and pending lawsuits — plaintiffs, defendants, jurisdictions, outcomes, and notable rulings.

✓ Generated

I'll research the litigation dockets for US 9,189,787 across the sources you named.

Let me gather more specific docket details and check for any recent filings.

Litigation Involving US 9,189,787

Scope note. I searched specifically for the literal number 9189787 and excluded similar numbers (9,187,977; 9,189,777; 9,187,987 etc.). Every hit resolves to US 9,189,787 B1. I cross-checked: the patent's own Google Patents front page (litigation list), the Unified Patents litigation/PTAB portal, Docket Alarm dockets, and RFCyber's own mandatory notices and complaints filed in the related cases. Results below build on — and are consistent with — the post-grant/litigation section already generated; I do not repeat the PTAB detail except where it bears on a case's status.

One point I must flag up front: the litigation I can identify is all RFCyber-as-plaintiff infringement litigation plus Apple's Federal Circuit appeal. I found no declaratory-judgment action in which 9,189,787 was the accused patent, and no ITC Section 337 investigation naming it. If such a matter exists, it is not surfacing in the sources I can reach.


District court cases naming the '787 patent

# Plaintiff Defendant(s) Court / Jurisdiction Case No. Filed Outcome / current status
1 RFCyber Corp. Google LLC and Google Payment Corp. [E.D. Tex. (Marshall), Judge Gilstrap](/courts/e-d-tex-marshall-judge-gilstrap) 2:20-cv-00274-JRG (lead case) Aug. 21, 2020 Settled — dismissed. Joint notice of settlement 2022-02-10; deadlines stayed 2022-02-11; order granting dismissal 2022-03-28; terminated 2022-03-28. Google's parallel IPRs (IPR2021-00954/55/56/57) terminated as settled on 2021-10-20.
2 RFCyber Corp. [[Samsung Electronics Co.](/litigations/by-defendant/Samsung%20Electronics%20Co.), Ltd.](/litigations/by-plaintiff/Samsung%20Electronics%20Co.%2C%20Ltd.) and Samsung Electronics America, Inc. E.D. Tex. (Marshall), Judge Gilstrap / Mag. Judge Payne 2:20-cv-00335-JRG-RSP (member case to 2:20-cv-00274) Oct. 16, 2020 Settled. Second mediation (David Folsom) successful 2022-02-10; joint motion to stay and notice of settlement 2022-02-10; stayed 2022-02-11.
3 RFCyber Corp. LG Electronics, Inc. E.D. Tex. (Marshall), Judge Gilstrap 2:20-cv-00336-JRG-RSP Oct. 16, 2020 Dismissed with prejudice. AO-120 report shows final judgment: "all pending claims and causes of action … are DISMISSED WITH PREJUDICE" (Sept. 2021).
4 RFCyber Corp. Apple, Inc. [W.D. Tex. (Waco), Judge Albright](/courts/w-d-tex-waco-judge-albright) 6:21-cv-00916-ADA Sept. 7, 2021 Co-pending with Apple's IPR2022-00412 (FWD 2023-07-18, all 19 claims sustained). Case stayed pending IPR. NOTE: parts of RFCyber's indirect/willful claims were previously dismissed in the W.D. Tex. Apple action, per VW's briefing below. Current 2026 status not confirmed.
5 RFCyber Corp. Visa U.S.A. Inc. W.D. Tex. (Waco), Judge Albright 6:22-cv-00697-ADA June 28, 2022 Settled and dismissed with prejudice (RFCyber's claims with prejudice; Visa's defenses without prejudice). Unopposed motion to stay/notice of settlement 2024-01-03; order of dismissal with prejudice signed February 2024; docket terminated Feb. 5, 2024.
6 RFCyber Corp. Unconfirmed W.D. Tex. 6:23-cv-00708 2023 Listed in the patent's front-page litigation data; parties and outcome not confirmed in the sources I could reach.
7 RFCyber Corp. Unconfirmed W.D. Tex. (Austin Div.) 1:23-cv-00661 2023 Listed in the patent's front-page litigation data; parties and outcome not confirmed.
8 RFCyber Corp. Volkswagen AG and Volkswagen Group of America, Inc. E.D. Tex. (Marshall), Judge Gilstrap 2:24-cv-00576-JRG July 23, 2024 Asserts the '787 alongside U.S. 8,118,218 and 8,448,855. Accused: Plug&Charge (ISO 15118) in VW/Audi/Porsche EVs and the Electrify America app. VWGoA moved to dismiss pre-suit willful/indirect claims 2024-09-30. One third-party case-tracking page lists the case as "Closed." I could not independently confirm the disposition document — treat the closure as tentative.

Sources: Google Patents front-page litigation list (https://patents.google.com/patent/US9189787/en); Unified Patents portal (https://portal.unifiedpatents.com/litigation/caselist); Docket Alarm dockets (e.g., https://www.docketalarm.com/cases/Texas_Eastern_District_Court/2--20-cv-00274/RFCyber_Corp._v._Google_LLC_et_al/, https://www.docketalarm.com/cases/Texas_Western_District_Court/6--22-cv-00697/RFCyber_Corp._v._Visa_U.S.A._Inc/, https://www.docketalarm.com/cases/Texas_Eastern_District_Court/2--24-cv-00576/RFCyber_Corp._v._Volkswagen_AG_et_al/); RFCyber's AO-120 filings and mandatory notices.


Federal Circuit proceedings

Appeal Parties Court No. Status
Apple Inc. v. RFCyber Corp. Apple (appellant) v. RFCyber (appellee) Fed. Cir. 2023-2396 Dismissed 2024-02-21. The court deconsolidated 23-2396 from 2023-2418, dismissed Apple's 23-2396 (Fed. R. App. P. 42(b)) and withdrew Apple from 23-2418. Procedural only — no validity finding.
RFCyber Corp. appeal re US 9,240,009 RFCyber (appellant) Fed. Cir. 2023-2418 The '009 patent appeal (not the '787). Board's unpatentability of the '009's claims was affirmed 2025-08-14. Apple was withdrawn as appellee.

The 2025–2026 appellate activity in RFCyber's portfolio (e.g., 24-1612; 24-1614, RFCyber Corp. v. Squires) concerns other family members, not the '787. As already flagged in the prior section, I did not locate any 2026 Federal Circuit docket directly adjudicating US 9,189,787; I cannot confirm one exists.


Direct answer to "List known litigation involving US patent 9189787"

Litigation is known and extensive — nine district-court matters and two Federal Circuit appeals. RFCyber has asserted the '787 (usually alongside U.S. 8,118,218, 8,448,855, 9,240,009 and/or 10,600,046) against Google, Samsung, LG, Apple, Visa, and Volkswagen/VW Group of America, with two additional 2023 W.D. Tex. dockets (6:23-cv-00708, 1:23-cv-00661) whose parties I could not confirm. The disposition pattern is uniform: every case resolved without a merits judgment against RFCyber — Google, Samsung, LG, and Visa settled/dismissed; Apple's invalidity case (IPR2022-00412) went to a final written decision that sustained all 19 claims, and Apple's appeal was dismissed; Volkswagen is the only matter that may still have been live, and it appears closed.


Confidence and open items

  • High confidence on items 1–5 and 8 as to court, case number, filing date, and the settlement/dismissal events cited (grounded in docket entries and orders quoted above).
  • Low confidence on the identity/outcome of 6:23-cv-00708 and 1:23-cv-00661 — parties NOT confirmed; I did not verify them and will not guess.
  • Unresolved: the exact current (April 2026) status of the Apple W.D. Tex. action (6:21-cv-00916) and the Volkswagen matter (2:24-cv-00576). Dockets move; confirm on PACER/CourtListener before relying on either.
  • Date discrepancy (carried forward): the Unified Patents feed reports the '787's derived dates one day off from the USPTO front page (2026-10-17 vs. 2026-10-18 expiration, etc.). I treat the front-page values as authoritative. Also note your prompt's operative date (April 26, 2026) differs from the system date; I have used the April date for "current status" framing.

Generated 9/28/2026, 5:21:01 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: RFCyber Corp.

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.

✓ Generated

I'll verify the PTAB record with live searches, prioritizing the ODP structured block vs. what the patent front page and public dockets show.

Good data. Now let me verify the CAFC appeal disposition, whether IPR2021-00980 was instituted, and any 2025–2026 activity.

PTAB / AIA Trial Proceedings — US 9,189,787

⚠️ First, a source conflict you must know about

The structured "PTAB proceedings on file" block in this prompt states that the USPTO ODP API returns no AIA trial proceedings for this patent, and directs that the default be "no PTAB activity on file."

That is contradicted by the authoritative record. The patent's own front page — reproduced verbatim in the full patent text supplied to me — lists three AIA trials (IPR2021-00955, IPR2021-00980, IPR2022-00412), a Final Written Decision, and an IPR certificate (K1) entered 2024-03-29. My live searches confirm each one against primary documents (the FWD PDF, the Board's termination order, the docket, and the Federal Circuit order).

Per the operating rules ("prefer… results that contradict"), and because the patent front page is designated authoritative, I treat the ODP "no proceedings" result as an indexing gap, not as evidence of absence. I report the three proceedings below and flag the conflict rather than defaulting to "no PTAB activity." If your workflow truly requires the ODP field to control, then the honest statement is: ODP is silent, but the real docket shows three IPRs — this is a data-completeness failure in the ODP ingest, not a clean patent.


Proceedings overview

Three AIA trials have been filed against the '787 — all Inter Partes Reviews: one reached a Final Written Decision and the Patent Owner won on all 19 claims; two were terminated by settlement before any merits decision. Bottom line for a defendant today: no claim of US 9,189,787 has ever been canceled or even held unpatentable. This is a hardened, not a narrowed, patent — claims 1–19 stand exactly as issued, the only FWD is now final and non-appealable, there is no IPR estoppel-bearing loss to exploit, and an IPR-based invalidity defense must be built from scratch against a Patent Owner that has already beaten Apple, Google and Samsung at this venue.

# Proceeding Petitioner Filed Status Claims canceled
1 IPR2022-00412 Apple Inc. 2022-01-14 FWD — no challenged claims unpatentable; appeal dismissed None (1–19 sustained)
2 IPR2021-00980 Samsung Electronics America / Samsung Electronics Co. 2021-06-08 Terminated — settled None
3 IPR2021-00955 Google LLC 2021-05-19 Terminated — settled, pre-institution None

IPR2022-00412 — Apple Inc. v. RFCyber Corp.

  • Type: Inter Partes Review (35 U.S.C. §§ 311–319)
  • Filed: 2022-01-14 (Paper 1). Apple also filed a Motion for Joinder to IPR2021-00980 (Paper 3), representing the petition was substantially identical to Samsung's.
  • Status: Final Written Decision (Google Patents legal-events entry: "PTAB case IPR2022-00412 filed (Final Written Decision)"); docket status "Final Written Decision – Appealed"; terminated 2023-07-18.
  • Judge panel: Kevin F. Turner, Patrick R. Scanlon, and Kevin W. Cherry, Administrative Patent Judges; APJ Scanlon authored the Final Written Decision. (Same panel as the consolidated IPR2022-00413 for the '009 patent.) The Board is in Tech Center 2800, Art Unit 2887.
  • Petition grounds: Claims 1–19, challenged under 35 U.S.C. § 103(a). Ground 1: Dua (US 2006/0165060) in view of GlobalPlatform Card Specification v2.1.1 (Mar. 2003) and Philips SmartMX P5CT072 Secure Dual Interface PKI Smart Card Controller Specification (Oct. 2004). Apple's theory: Dua supplied the portable device / wallet-application / extensions architecture and both transaction interfaces (short-range RFID and wireless network); Philips' SmartMX supplied the pre-loaded MIFARE "emulator"; GlobalPlatform supplied the two-channel personalization/security architecture. No § 102 or § 112 ground appears to have been pressed as the primary challenge.
  • Institution decision: Instituted 2022-07-21 on all challenged claims (1–19) on all grounds asserted in the Petition. The Board applied SAS Institute v. Iancu and 37 C.F.R. § 42.108(a) to institute on the full petition, finding "a reasonable likelihood that Petitioner would prevail in establishing the unpatentability of at least one of the challenged claims of the '787 patent." Because IPR2021-00980 had already terminated by then, the Board dismissed Apple's joinder motion as moot (Dec. Inst. 2 n.1). Apple had argued against Fintiv discretionary denial on the ground that the parallel W.D. Tex. case against Apple was at its earliest stage.
  • Final Written Decision: Issued 2023-07-18. Verdict, verbatim from the judgment: "Final Written Decision Determining No Challenged Claims Unpatentable — 35 U.S.C. § 318(a)"; "we determine that Petitioner has not shown by a preponderance of the evidence that claims 1–19 of the '787 patent are unpatentable."
    • Independent claims canceled: none. Dependent claims canceled: none. Claims held patentable: 1–19 — the entire challenged set.
    • Claim-level granularity: the FWD's captioned judgment and the challenger's burden statement are global to claims 1–19 (claims 1 and 11 are the only independents). The substantive fight is documented in Patent Owner's briefing as centering on (i) no motivation to combine Dua with GlobalPlatform and (ii) no disclosure of the "emulator … for storing security values and updated transaction logs," the "personalized" emulator, m-commerce "against a fund stored in the emulator," the first-channel/second-channel personalization architecture, and the SAM "external to the smart card module" limitations of claims 6/16. I want to be precise here: I retrieved the FWD's judgment and the parties' briefs, not the FWD's internal § III analysis, so I am not asserting which of Patent Owner's arguments the Board adopted or the exact wording of its reasoning. If you need the Board's reasoning verbatim, read Paper 30 at the link below.
    • Oral hearing held 2023-04-21 (record of hearing: Paper 29; consolidated with IPR2022-00413).
    • IPR certificate (Kind code K1) issued effective 2024-03-29, per the patent's legal-events record — the formal confirmatory certificate under 35 U.S.C. § 318(b).
  • Settlement / termination: Not settled. Decided on the merits.
  • Appeal: *Yes — CAFC No. 2023-2396, Apple Inc. v. RFCyber Corp., appeal from PTAB No. IPR2022-00412.* Disposition: dismissed 2024-02-21 on Apple's FRAP 42(b) motion; the appeals were deconsolidated from No. 2023-2418, Apple withdrew as appellee from 2023-2418, and "Each side shall bear its own costs regarding Appeal No. 2023-2396." The order is nonprecedential and makes no validity finding — it is purely procedural. (Note: No. 2023-2418 is RFCyber's appeal concerning the '009 patent, not the '787.)
  • Defensive value: Weakest possible IPR posture for a defendant. Apple — a sophisticated, well-funded petitioner with an expert who had served on the GlobalPlatform board — lost on every one of claims 1–19, and the FWD is now final and unappealable. Any § 103 theory built on Dua + GlobalPlatform + Philips is effectively dead: it has been fully litigated and lost, and importing it into a new IPR invites § 325(d) discretionary denial and an obviousness judgment pre-rejected by the Board. A defendant needs different primary art, and needs to beat the same "motivation to combine" wall Apple hit.

IPR2021-00980 — Samsung Electronics America, Inc. and Samsung Electronics Co., Ltd. v. RFCyber Corp.

  • Type: Inter Partes Review
  • Filed: 2021-06-08 (Petition for IPR of claims 1–19 of US 9,189,787).
  • Status: Terminated — Settled (Unified Patents structured status "Settlement"; docket status "Terminated–Settled"). Termination date 2022-04-11. The patent's legal-events record gives the effective filing/2021-06-08 and a PTAB entry with Petitioner "SAMSUNG ELECTRONICS AMERICA, INC., AND SAMSUNG ELECTRONICS CO., LTD."
  • Judge panel: Kevin F. Turner, Patrick R. Scanlon, and Kevin W. Cherry. ⚠️ Note a mid-proceeding panel change: a Panel Change Order dated 2022-02-17, issued by Deputy Chief APJ Jacqueline Wright Bonilla, states that "Due to unavailability, Administrative Patent Judge Kevin F. Turner replaces Administrative Patent Judge Kristi L. R. Sawert on the panel." So the original panel included APJ Sawert, replaced by APJ Turner.
  • Petition grounds: Claims 1–19 under 35 U.S.C. § 103 — Ground 1: Dua in view of GlobalPlatform and Philips, i.e., the same combination Apple later copied into IPR2022-00412 (Apple conceded its petition was "substantially identical"). Patent Owner's preliminary response argued the Fintiv factors (all six) favored discretionary denial.
  • Institution decision: ⚠️ I could not retrieve a standalone institution decision for IPR2021-00980, and I will not invent a date for it. The weight of the record indicates it was instituted:
    • Apple's Motion for Joinder under § 315(c) targeted IPR2021-00980 — joinder at that stage presupposes an existing instituted IPR;
    • RFCyber's own district-court Notice Regarding IPRs (2022-01-31) in RFCyber v. Apple states Apple filed IPRs "seeking joinder to instituted IPRs filed by Samsung";
    • The parties' stated expected FWD date was 2022-12-15, which corresponds to a § 316(a)(11) one-year deadline running from institution on/about 2021-12-15.
      Treat "instituted ~2021-12-15, then settled 2022-04-11" as well-supported but not confirmed by a document I read.
  • Final Written Decision: None — no FWD ever issued. No claim was ever canceled, held valid, or adjudicated in this proceeding. Claims 1–19 emerge untouched. This matters for estoppel (see below): no § 315(e) estoppel attached to Samsung.
  • Settlement / termination: The proceeding ended in settlement. As is customary, the settlement terms are confidential and were not made public; I have no visibility into the terms (and I will not speculate about a license). A parallel settlement/resolution of the E.D. Tex. case against Samsung (2:20-cv-00335) accompanied it.
  • Appeal: None. No FWD, nothing to appeal.
  • Defensive value: Neutral-to-negative for a defendant. Samsung got the trial instituted and then bought its way out without a merits ruling — so there is no adverse PTAB finding against the '787 available to borrow, and equally no estoppel binding Samsung. If you are a Samsung-linked or Samsung-privity defendant, the practical problem is the confidential license, not estoppel. Your best use of this docket is as evidence of prior art already presented and thus § 325(d) bait: re-running Dua + GlobalPlatform + Philips as a "new" ground is exactly the kind of repeat challenge the Board exercises discretion to deny.

IPR2021-00955 — Google LLC v. RFCyber Corp.

  • Type: Inter Partes Review
  • Filed: 2021-05-19 (Unified Patents structured field: Filing Date 2021-05-19). One of four IPRs Google filed that same day against the four-patent RFCyber family: IPR2021-00954 ('855), IPR2021-00955 ('787), IPR2021-00956 ('009), IPR2021-00957 ('218).
  • Status: Terminated — Settled, pre-institution. Unified Patents: Status "Settlement", Termination Date 2021-10-20, Institution Date "N/A." The docket shows "Termination Decision Pre DI settlement — DECISION Granting Joint Motion to Terminate Due to Settlement Prior to Institution."
  • Judge panel: Patrick R. Scanlon, Kevin W. Cherry, and Kristi L. R. Sawert, Administrative Patent Judges (per the joint termination decision, which addressed IPR2021-00954/-00955/-00956/-00957 together).
  • Petition grounds: Claims challenged included claims 1, 2, 4–12, and 14–19 under Ground 1 — obvious over Staib (US 2005/0222961 A1) in view of Chan (US 6,005,942). Supporting exhibits included Holtmanns (US 7,628,322), Wentker (US 6,481,632), Pesonen (US 7,699,233), Lee (US 6,367,011), and the Smart Card Handbook (Rankl & Effing, 3d ed.). ⚠️ Caveat: the petition's table of contents that I retrieved shows Ground 1's claim list as "1, 2, 4-12, and 14-19" — i.e., claims 3 and 13 are absent from Ground 1, implying a further ground for those two claims that I did not retrieve. Do not assume claims 3 and 13 were unchallenged. Google argued the Fintiv factors favored institution.
  • Institution decision: None. No institution decision was ever issued — the case terminated while still in the preliminary proceeding. RFCyber filed its Patent Owner Preliminary Response 2021-08-24 (with subpoena-related exhibits against Nokia, GlobalPlatform, NFC Forum, Mastercard, NXP, Visa and Sequent Software); Google filed its Reply to the POPR 2021-09-15; the parties jointly moved to terminate 2021-10-19.
  • Final Written Decision: None. No FWD, no claim-level findings whatsoever. Claims 1–19 are entirely untouched by this proceeding.
  • Settlement / termination: Settled. The Board's decision states the parties "have settled their dispute regarding the patents challenged in these inter partes review proceedings" and **also settled the related district-court litigation, RFCyber Corp. v. Google LLC and Google Payment Corp., No. 2:20-cv-00274-JRG (E.D. Tex.)**, and "do not anticipate further litigation between them" over the challenged patents. A true, unredacted copy of a "settlement and license agreement" was filed (Ex. 1040) and, on the parties' joint request, treated as business confidential information under 35 U.S.C. § 317(b) and 37 C.F.R. § 42.74(c) — the terms are not public. The Board dismissed Google's petitions under 37 C.F.R. §§ 42.5(a), 42.71(a), and a Notice of refund approved issued 2021-10-26 (consistent with no institution).
  • Appeal: None. Nothing to appeal.
  • Defensive value: No claim-level ammunition, and a binding subtlety worth flagging. Because termination came pre-institution, no § 315(e)(1) or (e)(2) estoppel attached to Google — Google is free to raise the Staib + Chan art again. But the filed settlement-and-license agreement (Ex. 1040) is a real asset: it very likely gives Google an express license to the '787. If you are accused based on a Google Pay implementation, immediately investigate whether your supply chain sits under that license (note, however, that a bare patent license is not a first sale and does not exhaust as to downstream products without an authorized sale — get counsel on that). For everyone else, Ex. 1040 is a sealed document; you will not get its terms absent a protective-order fight or a third-party subpoena.

Strategic summary

Claim status after three IPRs — nothing has been lost. CANCELED: none. SUSTAINED: claims 1–19, all of them (the only merits decision, IPR2022-00412 FWD of 2023-07-18, found no challenged claim unpatentable and was confirmed by the K1 IPR certificate effective 2024-03-29, with the appeal dismissed 2024-02-21). UNTESTED: none. The claims of the '787 come out of the PTAB identical to the way they issued on 2015-11-17: independent device claim 1, independent method claim 11, and dependents 2–10 and 12–19. This is the opposite of a narrowed patent, and any demand letter you receive will cite live, fully intact claims — including the very claims (1, 2, 6, 8, 11) RFCyber elected to assert against Samsung and the Apple Pay / Apple Wallet products. Note the assertion pattern that emerged in litigation: RFCyber asserted claims 1–3, 6, 8, 11, 13, 16, 18 against Samsung in the claim-construction record, and elected claims 1, 2, 6, 8, 11 at final election — a small, stable, well-rehearsed set that has survived an FWD.

Estoppel landscape. Only Apple bears statutory IPR estoppel. Under 35 U.S.C. § 315(e)(2), Apple (and its real parties in interest and privies) is estopped in the district court and ITC from asserting that claims 1–19 are invalid on any ground raised in IPR2022-00412 or that Apple reasonably could have raised — i.e., the Dua + GlobalPlatform + Philips § 103 combination, and any art a skilled petitioner reasonably could have raised in that trial. Crucially, Google and Samsung are not estopped: Google's IPRs terminated pre-institution, and Samsung's terminated before any FWD, and § 315(e) estoppel attaches only after a final written decision. So for a defendant currently accused, the honest answer to "what art is still available?" is: all of it — except the Dua/GlobalPlatform/Philips combination as to Apple, and except that a re-run of that same combination by you will run straight into § 325(d) discretionary denial. The Estoppel gap is real, but it is a political rather than a legal obstacle: the Board has now twice instituted on Dua + GlobalPlatform (Samsung 2021, Apple 2022) and once rejected it on the merits — a fourth bite at the same apple will be viewed skeptically. Your realistic paths are (a) different primary art with a materially different motivation-to-combine story, (b) a § 112 or § 102 attack never squarely joined in the IPRs, or (c) the district-court invalidity case, where Apple's actual loss does not bind anyone and a jury may see the art differently.

Pattern signals. (i) Repeat-petitioner pattern is strong. Google filed four IPRs in a single day (2021-05-19) covering the entire RFCyber family ('855, '787, '009, '218) and then licensed its way out of all four in one global settlement with the district case on 2021-10-20 — a coordinated, litigation-driven filing, not an isolated challenge. Samsung filed four the next month ('787, '009, '855, '218); two were denied institution on 2021-12-14 (IPR2021-00978 as to the '855 patent, and its '218 companion), and two were instituted and then settled. Apple then filed two more (IPR2022-00412 / -00413) as joinder-copies of the instituted Samsung challenges. This is the classic NPE-campaign counter-punch — three separate large operating companies each paid to make the '787 go away, and the one that fought to judgment lost. (ii) Patent Owner plays PTAB aggressively and wins. RFCyber defended IPR2022-00412 to a full FWD on all claims, then saw Apple walk away from the appeal rather than brief it. (iii) Defensive aggregator involvement — negative finding. I found no Unified Patents (or other aggregator) IPR on the '787 in the chain; the Google Patents "Family has litigation" field links Unified Patents litigation portals (IPR2021-00955, IPR2021-00980, IPR2022-00412 and the district dockets) purely as data citations, not as an assertion by Unified. Do not read "Unified" in those URLs as Unified Patents challenging the patent. (iv) The current front is district court, not the Board. RFCyber's 2024 E.D. Tex. campaign (Costco, Kroger, Shell, Starbucks (lead), Walmart, Volkswagen/Electrify America) is IPR-silent so far — and, per the prior section's flag, the '787's linkage to the 2024 complaints is family-level attribution only on the records I could inspect; those complaints pleaded the '218 and '855 patents. No 2025 or 2026 IPR petition on the '787 surfaced in my searches, and the ODP block reports none.


Recommended next steps

  1. If your demand letter cites claims 1, 2, 6, 8, 11 (or 3, 13, 18) and you were hoping for a PTAB shortcut: there isn't one. No claim of the '787 has ever been canceled, so there is no FWD to hand the court and no canceled-claim argument to make. Read the actual loss-letter opinion — the IPR2022-00412 Final Written Decision (Paper 30, 2023-07-18), which reads in its judgment line: "Final Written Decision Determining No Challenged Claims Unpatentable 35 U.S.C. § 318(a)" and "Petitioner has not shown by a preponderance of the evidence that claims 1–19 of the '787 patent are unpatentable" — at https://www.docketalarm.com/cases/PTAB/IPR2022-00412/Apple_Inc._v._RFCyber_Corp/docs/07-18-2023-Board/Final_Written_Decision__original-30-Final_Written_Decision__original.pdf , and the institution decision at https://www.docketalarm.com/cases/PTAB/IPR2022-00412/Apple_Inc._v._RFCyber_Corp/07-21-2022-Board/Institution_Decision__Grant-11-Granting_Institution_of_Inter_Partes_Review_and_Dismissing_Petitioners_Motion_for_Joinder_as_Moot/ . This FWD is adverse authority you must design around, not a weapon.
  2. If you are accused and considering a new IPR: the art must be different from Dua + GlobalPlatform + Philips. That combination has been instituted twice, briefed to an FWD once, and rejected — a third petition on it will draw § 325(d) and § 314(a) discretionary-denial fire. Budget for a new primary reference and a motivation-to-combine theory that survives the "no reason to import GlobalPlatform into a SIP-based system" attack that RFCyber ran successfully in IPR2022-00412 (and see Patent Owner's Sur-Reply, Paper 23, 2023-03-09, for the exact framing RFCyber will reuse against you).
  3. Timing/milestone note — there are no live PTAB milestones to track. All three proceedings are closed (2022-04-11 and 2021-10-20 terminations; 2023-07-18 FWD; 2024-02-21 CAFC dismissal; 2024-03-29 K1 certificate). There is no institution-decision deadline, no oral hearing, and no § 316(a)(11) FWD due date to calendar. If a new petition is filed, the statutory clock runs one year from institution for the FWD, and the § 314(b) institution deadline is six months from the petition's filing date (subject to the Director's guidance).
  4. Chase the two documents that could change your exposure. (a) The Google settlement and license agreement, Ex. 1040 in IPR2021-00955 — sealed as business confidential under § 317(b)/§ 42.74(c), but potentially dispositive if you are accused over a Google-sourced payment stack. (b) The IPR2021-00980 settlement with Samsung — also confidential. Both may be obtainable in your district case via a protective order or third-party subpoena.
  5. Verify the two open items I could not confirm before relying on them: (i) the IPR2021-00980 institution decision and date (I inferred institution ~2021-12-15 from Apple's joinder motion, RFCyber's "instituted IPRs" notice, and the parties' 2022-12-15 expected-FWD date — but I did not read the document); and (ii) whether Google's petition challenged claims 3 and 13 in a ground other than Ground 1. Both are checkable in PTAB E2E / PTAB Center at https://ptacts.uspto.gov/ptacts/ by entering the proceeding numbers, and the FWD is on the Board's decisions site at https://www.uspto.gov/patents/ptab/decisions .
  6. Re-check ODP ingest. The "no AIA trial proceedings" result in the structured block is demonstrably wrong. If your tooling gates PTAB sections on that field, fix it — this patent's outcome (a fully-surviving FWD plus two settlements) inverts the default "well-asserted patents have some canceled claims" heuristic, and silently reporting "no PTAB activity" here would be a materially misleading result.

Confidence

  • High confidence (primary documents read): IPR2022-00412 filed 2022-01-14; instituted on all claims 1–19 on 2022-07-21 over Dua + GlobalPlatform + Philips under § 103; FWD 2023-07-18 finding no challenged claims unpatentable; panel Turner/Scanlon/Cherry with Scanlon authoring; oral hearing 2023-04-21; CAFC 2023-2396 dismissed 2024-02-21 with no validity finding; IPR certificate K1 effective 2024-03-29. IPR2021-00955 filed 2021-05-19, terminated pre-institution 2021-10-20 by settlement (§ 317), panel Scanlon/Cherry/Sawert, Ground 1 = Staib + Chan on claims 1, 2, 4–12, 14–19, settlement-and-license agreement sealed as business confidential. IPR2021-00980 filed 2021-06-08, terminated by settlement 2022-04-11, panel-change order 2022-02-17 (Turner replacing Sawert).
  • Moderate confidence: that IPR2021-00980 was instituted (inferred from Apple's § 315(c) joinder motion, RFCyber's "instituted IPRs" district-court notice, and the parties' 2022-12-15 expected-FWD date — no institution document retrieved); the specific § III reasoning the Board adopted in the IPR2022-00412 FWD (I read the judgment and the briefs, not the full opinion body); the existence/content of a second ground in Google's IPR2021-00955 petition covering claims 3 and 13.
  • Explicit negative findings: no claims of US 9,189,787 have ever been canceled or held unpatentable; no FWD other than IPR2022-00412 exists; no 2025–2026 IPR petition against the '787 surfaced; no Unified Patents (or other defensive-aggregator) IPR against the '787; and the USPTO ODP structured block's "no proceedings" result is contradicted by the patent front page and by three verified proceedings.

Generated 9/28/2026, 5:21:47 PM

Ownership chain (5)

Asserters network →

Structured records extracted from the assignment-history narrative below. Each entity links to its full ownership-network profile.

  1. 2020-07-30 · recorded 2020-08-06 · reel 053424/0463 · Assignment

    RFCYBER CORPORATION (California)RFCyber Corp. (Texas)

    transfer-to-asserter

  2. 2020-07-30 · License

    Shenzhen RFCyber Asset Management, LLPRFCyber Corp. (Texas)

    rights-clearing

  3. 2021-07-30 · Confirmatory Assignment

    Shenzhen RFCyber Asset Management, LLPRFCyber Corp. (Texas)

    standing cure

  4. ? · Assignment

    Liang Seng Koh; Futong Cho; Hsin Pan; Fuliang ChoRFCyber Corp. and Rich House Global Tech Ltd

    original title formation

  5. ? · Assignment

    RFCyber CorporationShenzhen RFCyber Asset Management, LLP

    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.

✓ Generated

I'll reconstruct the assignment chain from primary records. Let me pull the USPTO assignment data and cross-reference the corporate history.

Good yields. Let me now pin down the specific reel/frame records and the earlier links in the chain.

Assignment & Ownership Reconstruction — US 9,189,787 B1

Method note / limitation up front. I retrieved the ownership chain from two source classes: (a) the patent's own front-page legal-events table (authoritative per your source rules), and (b) RFCyber's own sworn court admissions reciting the assignment documents as exhibits (Ex. 5, Ex. 6, Ex. C–E in RFCyber Corp. v. Google LLC, 2:20-cv-00274-JRG (E.D. Tex.), Dkt. 92). I was able to confirm exactly one reel/frame number — Reel 053424/0463. The remaining links are documented as to parties, dates and conveyances but I could not retrieve their reel/frame numbers or their correspondent of record in this pass. Where that is the case I say so rather than supplying a plausible-looking reel number. This is the single largest evidentiary gap in this memo.

Also flagging a genuine contradiction to reconcile: the Google Patents front page lists "Rich House Global Tech Ltd" as both an original and a current assignee, yet the only assignment event on that page (2020) runs RFCYBER CORPORATION → RFCYBER CORPORATION (Texas) with no Rich House entry. Either Rich House remains a co-owner with no recorded divestiture, or the front-page assignee field is stale. Do not treat RFCyber as the sole record owner without pulling the recorded documents.


Inventors

Inventor Residence of record Apparent employer at filing
Liang Seng Koh Fremont, CA RFCyber Corp. (Fremont, CA)
Futong Cho Milpitas, CA RFCyber Corp. (Fremont, CA)
Hsin Pan Fremont, CA RFCyber Corp. (Fremont, CA)
Fuliang Cho San Jose, CA RFCyber Corp. (Fremont, CA)
  • Basis for the employer attribution (moderate-high confidence): all four are the named inventors across the sibling RFCyber filings — e.g., the '218 parent (11/534,653) and the '855 (13/400,038) list the identical four (see Shenzhen RFCyber's Mandatory Notices, IPR2022-01240; RFCyber's Mandatory Notices, IPR2022-00413). That co-inventor set is the RFCyber founding team. I did not find an executed employment/assignment agreement in the record; the attribution rests on portfolio overlap plus RFCyber's status as prosecuting assignee, not on a produced document.
  • Conception date: RFCyber has repeatedly asserted a December 2004 conception date with reduction to practice evidenced by source code (Patent Owner's Sur-Reply, IPR2021-00980, Paper 10). Inventors' assignment was therefore ~21 months after conception and coincident with the Sept. 2006 filing.
  • Unusual pattern — present. There is no evidence of inventor departure/portfolio fire-sale. The unusual pattern here is different and more relevant to your chain question: the inventors assigned into two parallel owners (a Fremont, CA operating company and a Shenzhen, China entity, Rich House Global Tech Ltd) whose relationship is not explained in any record I found, and the resulting chain-of-title ambiguity was later litigated (Samsung's motion to dismiss for lack of constitutional standing, Dkt. 81, July 16, 2021). That is the unusual feature, not attrition.

Original assignee

  • RFCyber Corp. — Fremont, CA. Corporate address in the record: 4160 Technology Drive, Suite A, Fremont, CA 94538 (RFCyber product literature, rfcybercorp.com).
  • Co-named on the face: Rich House Global Tech Ltd — Shenzhen, China. Described in secondary coverage as the recipient of a transfer of "a few [patents]" from the RFCyber portfolio.
  • Did they ship a product embodying the claims? YES — this is not a paper patent. RFCyber's published product suite maps almost 1:1 onto the '787's claims: a Trusted Service Management (TSM) platform managing the secure element lifecycle; a Mobile Financial Service (MFS) platform whose ePurse ("created based on PBOC 2.0") "can be consumed using RFID interface, or via mobile commerce interface" and "can also be reloaded via the MFS connection to the banking network" — i.e., the dual-interface e-purse of claim 1; and MPT / Mobile POS products. RFCyber also documented real field deployments (Breda, Netherlands social-care e-voucher on Nokia 3220/6131i, Aug. 2007; Chunghwa Telecom / China Trust / Visa / Nokia NFC smart-poster program, Sept. 2007) and states it was "the first company to provide OTA ePurse reloading."
  • Current status: The Fremont entity survives as the holding company — RFCyber Corp. (Texas) filed a Corporate Disclosure Statement "identifying Corporate Parent RFCyber Corporation for RFCyber Corp." (Dkt. 3, Oct. 16, 2020). The asserting entity is the Texas corporation, described in an IEEE seminar acknowledgment as "a Texas registered company since 2020… offices at Plano and Waco," sponsoring university research. No bankruptcy, no dissolution record found.

Assignment timeline

Only one entry carries a verified reel/frame. Entries marked (r/f unretrieved) are established by RFCyber's court admissions but I could not pull the recordation metadata.

  • 2006-09-24 (conception-to-filing window; exact execution date unretrieved) / recorded unretrieved — Reel unretrieved

    • Conveyance: Assignment (inventors → assignee) — inferred from the face of the patent, not individually confirmed
    • Assignor: Liang Seng Koh; Futong Cho; Hsin Pan; Fuliang Cho
    • Assignee: RFCyber Corp. (Fremont, CA) and Rich House Global Tech Ltd (Shenzhen, CN)
    • Correspondent: not retrieved
    • Context: Formation of the original title that later became clouded — the two-assignee structure is the root of the 2021 standing dispute.
  • 2014-01 (executed; day not stated) / recorded unretrieved — Reel unretrieved

    • Conveyance: Assignment
    • Assignor: RFCyber Corporation, Fremont, CA ("RFCyber Holding")
    • Assignee: Shenzhen RFCyber Asset Management, LLP (Shenzhen, CN)
    • Correspondent: not retrieved
    • Context: Offshoring/restructuring. Scope is contested: RFCyber's brief (Dkt. 92 at §B) states the January 2014 assignment "only was effective as to the '218 and '855 patents," and that RFCyber Holding "prosecuted the applications that issued as the patents at issue" and "is listed as the assignee on each of those patents." Meaning: the '787 was NOT intended to travel in this link — but the document's actual language was disputed, which is why it later required cure.
  • 2020-07-30 (executed) / recorded 2020-08-06 — Reel 053424/0463 ✅ (verified)

    • Conveyance: ASSIGNMENT OF ASSIGNOR'S INTEREST (see document for details)
    • Assignor: RFCYBER CORPORATION (California)
    • Assignee: RFCYBER CORPORATION, TEXAS — per Google Patents legal-events entry: "Owner name: RFCYBER CORPORATION, TEXAS … ASSIGNMENT OF ASSIGNOR'S INTEREST;ASSIGNOR:RFCYBER CORPORATION;REEL/FRAME:053424/0463 … Effective date: 20200730."
    • Correspondent: not retrieved — and this is the correspondent you most want (see Signal 3).
    • Context: Transfer-to-asserter / intra-group reorganization onto a freshly formed Texas plaintiff. ~11 weeks before the first complaint in the campaign.
  • 2020-07-30 (executed) / recorded unretrieved

    • Conveyance: Exclusive License (not a title transfer)
    • Assignor: Shenzhen RFCyber Asset Management, LLP
    • Assignee: RFCyber Corp. (Texas)
    • Correspondent: not retrieved
    • Context: Rights-clearing. Covers the '218 and '855 and, by its terms, "all patent applications, patents to be issued pursuant thereto, divisional, continuations, continuations-in-part, reissues, substitutes, and extensions thereof" — drafted as a standing patch.
  • 2021-07-30 (executed) / recorded unretrieved

    • Conveyance: Confirmatory Assignment
    • Assignor: Shenzhen RFCyber Asset Management, LLP
    • Assignee: RFCyber Corp. (Texas)
    • Correspondent: not retrieved
    • Context: Standing cure executed under litigation pressure. Samsung moved to dismiss for lack of standing 2021-07-16 (Dkt. 81); RFCyber's response states "RFCyber Shenzhen and Plaintiff RFCyber have since executed a confirmatory assignment for the patents at issue, which cures any purported standing issue." 14 days between the motion and the cure.
  • 2026-10-18 — adjusted expiration (not an assignment; included for term limits on any recovery).

Verification links: USPTO Assignment Center · legacy Assignment Search · Google Patents legal events for US 9,189,787


Timeline diagram

timeline
    title Ownership of US 9189787
    2006 : Priority application filed Sept 24
    2013 : Continuation filed May 28
         : Rich House Global Tech named co assignee
    2014 : RFCyber California assigns to Shenzhen RFCyber
    2015 : Patent issued Nov 17
    2020 : RFCyber California assigns to RFCyber Texas
         : Reel 053424 frame 0463
         : Google and Samsung suits filed within 11 weeks
    2021 : Confirmatory assignment from Shenzhen to RFCyber
         : Executed 14 days after standing motion
    2026 : Adjusted expiration Oct 18

NPE / troll-pattern signals

1. Shell-entity transfer — PRESENT (moderate).
Concrete evidence, not naming: Reel 053424/0463, executed 2020-07-30 / recorded 2020-08-06, moved the patent from RFCyber Corporation (Fremont, CA) — an entity with documented shipped products and named 2007 field deployments — to RFCYBER CORPORATION, TEXAS, an entity formed in 2020 whose only documented activity is (i) filing 13+ infringement suits and (ii) sponsoring university research. Caveat against over-reading: the name has no "IP / Holdings / Licensing" suffix, and the Texas entity does claim a product line (Web 3.0/blockchain/mobile payment), so this is not a bare licensing-only LLC. The finding rests on the date of formation + the litigation-only observable footprint, not on the name.

2. Known asserter in the chain — PRESENT (strong).
The Patent Owner is classified by Unified Patents as "NPE (Individual)" on the IPR2021-00955 case profile (portal.unifiedpatents.com/ptab/case/IPR2021-00955) — a third-party asserter-directory classification, exactly the kind of corroboration your instruction requires. It is not any of the listed roster names (Acacia, Marathon, IV, Wi-LAN/Conversant, Vringo, Pendrell, Round Rock, Spangenberg, etc.); RFCyber is a first-generation, inventor-backed asserter rather than a Transpacific-acquired shell. RFCyber's own pleadings confirm the posture: it "is the sole and exclusive owner of all right, title and interest to and in, or is the exclusive licensee with the right to sue for, the '218, '855, '787, '009, and '046 Patents."

3. Repeat correspondent across the chain — UNKNOWN / cannot responsibly score.
This is the signal I could not test, because the correspondent of record on the assignment recordings was not retrievable in this pass — including for the one reel/frame I confirmed (053424/0463). What I can state precisely is adjacent but different in kind: Fabricant LLP (Alfred Ross Fabricant; Vincent J. Rubino III, Reg. No. 68,594; Peter Lambrianakos; Richard Cowell; 411 Theodore Fremd Ave., Suite 206 South, Rye, NY 10580) is litigation and PTAB counsel of record in every RFCyber assertion I inspected — E.D. Tex. 2:20-cv-00274/-00335/-00336; W.D. Tex. 6:21-cv-00916, 6:22-cv-00697; and every IPR mandatory notice (IPR2021-00955 P.O. counsel; IPR2022-00412; IPR2022-00413). That is a repeat-player law firm across the campaign. I am not relabeling it as the assignment correspondent. Recommended action: pull the recorded assignment PDFs for 053424/0463 and the 2021 confirmatory assignment to capture the actual correspondent field — if Fabricant (or a single attorney) is the recurring correspondent, that converts this to a strong signal.

4. Cascading transfers — PRESENT (moderate).
Not a rapid <24-month LLC chain, but a different and equally diagnostic pattern: parallel/duplicative chains through an offshore entity. The title flows CA → Shenzhen (Jan. 2014, disputed scope) → Texas (2020-07-30) → Shenzhen confirmatory (2021-07-30). Two transfers are dated exactly 12 months apart (2020-07-30 and 2021-07-30), and the second exists only to paper over the first. The chain has a China intermediary (Shenzhen RFCyber Asset Management LLP) and a China co-owner on the face (Rich House Global Tech Ltd) — i.e., cross-border title complexity rather than a domestic shell cascade.

5. Pre-litigation transfer — PRESENT (strong).
The transfer to the asserting Texas entity was executed 2020-07-30 and recorded 2020-08-06 (Reel 053424/0463); the first campaign complaints followed within ~11 weeks (Google/Samsung E.D. Tex., filed Aug./Oct. 2020; Samsung's civil docket shows Date Filed: 10/16/2020). That is comfortably inside your 6-month window and is consistent with the transfer having been arranged to establish a clean Texas plaintiff and venue.

6. Bankruptcy fire-sale — NOT PRESENT.
No Chapter 7/11 filing, no trustee sale, no portfolio auction involving RFCyber or Rich House Global Tech Ltd was found. The 2014 and 2020 transfers are corporate restructurings, not distress sales.

7. Privateering — UNCLEAR.
The transferor (RFCyber Corporation, Fremont) was itself an operating supplier to the NFC-payments ecosystem (TSM/MFS/MPT deployments with Nokia, Chunghwa Telecom, Visa, China Trust), which is the factual predicate for privateering. But the transferee is an affiliate of the same corporate family, not an unrelated proxy, and I found no SEC filing or Patent Progress/EFF coverage evidencing a supply relationship as the motive for the transfer to the Texas entity. Score as unclear rather than asserting it.

8. Defensive aggregator (anti-NPE) — NOT PRESENT.
The chain terminates at an asserting entity (RFCyber Corp., Texas). No RPX, AST, LOT Network, Unified Patents, or OIN anywhere in the title chain. Note the trap: the "Unified Patents" links on the Google Patents page are the litigation-data portal only — Unified never acquired or neutralized this patent, and it is not a petitioner in any of the three IPRs (the petitioners were Google, Samsung and Apple).

Bonus signal — chain may not be 100% owned. The front page still lists Rich House Global Tech Ltd as a current assignee, and no divestiture by Rich House appears in the legal-events table. If Rich House remains a co-owner, RFCyber's assertion posture depends on the July 30, 2020/2021 instruments being effective against that interest — the precise defect Samsung attacked in its July 16, 2021 motion to dismiss.


Verdict

NPE — high confidence (2+ strong signals).

Two strong signals drive the call: (Signal 2) Unified Patents classifies the Patent Owner as "NPE (Individual)" and RFCyber is a 13-docket, five-patent serial filer; and (Signal 5) the patent was transferred to the freshly formed Texas asserting entity by Reel 053424/0463, executed 2020-07-30 and recorded 2020-08-06 — ~11 weeks before the first complaints in the E.D. Tex. campaign, squarely inside the pre-litigation-transfer window. Signal 1 (transfer away from a product-shipping Fremont company to a 2020-formed, litigation-only Texas entity) and Signal 4 (a two-track, cross-border chain through Shenzhen, including a confirmatory assignment executed 14 days after a standing motion) add substantial corroboration. This is not a Transpacific-style shell stack, and the underlying portfolio did ship real product — so this is best characterized as an inventor-backed operating company that restructured into a Texas assertion vehicle, not a classic acquired shell. Flagging explicitly: Signal 3 remains unscored because the assignment correspondent of record was not retrieved, and the Rich House Global Tech co-ownership question is unresolved on the current record — both should be closed out by pulling the recorded documents at assignmentcenter.uspto.gov for Reel 053424/0463 and the 2021 confirmatory assignment.

Generated 9/28/2026, 5:21:35 PM

Prior art

Earlier patents, publications, and products that may anticipate or render the claims unpatentable.

✓ Generated

I'll verify the patent record and its cited prior art against live sources before analysis.

Now let me verify the remaining cited references and the key IPR prior art.

Prior-Art Analysis — US 9,189,787 B1

("Method and apparatus for conducting e-commence and m-commence" — the misspellings are in the original and are reproduced literally, not corrected.)


1. Scope and verification

I searched for the exact string 9189787 and did not accept results for near-numbers. Every reference below is tied either to the '787's own front page ("Patent Citations" / "Family Cites Families" tables on Google Patents) or to a PTAB petition/exhibit that names U.S. Patent No. 9,189,787 expressly.

Two findings up front that shape the answer:

(a) The '787 has only TWO examiner-cited patent references on its face. This is unusually thin for a 19-claim software patent and is itself a relevant data point. Both are pre-2004–2005 documents, so both are unambiguously prior art to the 2006-09-24 effective priority date.

(b) The seriously dangerous art in this family is NOT on the patent's face — it is the art the petitioners found. The three IPRs (Google, Samsung, Apple) all attacked the '787 with the same combination of references that never appears among the examiner's citations: Dua + GlobalPlatform 2.1.1 + Philips SmartMX. That combination went to a Final Written Decision on the merits. If your question is "what is the most relevant prior art," the answer is that combination — not the face citations. I cover both.

Threshold legal note (flag, not resolution): the '787 was filed 2013-05-28 but is a straight continuation of 13/400,038 → 11/534,653 (2006-09-24). If no new matter was added, every claim's effective filing date is 2006-09-24 and pre-AIA §§ 102/103 govern; if any claim has an effective filing date on/after 2013-03-16, the AIA applies. I could not resolve this from the record fetched and I do not assert it. In practice the distinction is immaterial here: every reference below predates 2006-09-24, so it is prior art under either regime. Where the § 102 subsection matters I note it.


2. Master table of references

# Reference Pub. / filing date Source on '787 Type
R1 US 6,031,912 A (Banksys) Pub. 2000-02-29; priority 1994-09-09 Examiner citation (face) Patent, § 102(b)
R2 US 2005/0222961 A1 (Staib) Pub. 2005-10-06; filed 2004-09-14; prov. 60/559,818 filed 2004-04-05 Examiner citation (face) Application pub., § 102(a)/(e)
R3 US 6,607,136 B1 (Atsmon et al./BeepCard) Granted 2003-08-19; filed 2000-05-12; prio. 1998-09-16 Family-cited Patent, § 102(b)
R4 CA 2305249 A1 (Sarcanin) Pub. 2001-10-14; filed 2000-04-14 Family-cited Foreign pub., § 102(b)
R5 US 2002/0145632 A1 (Shmueli) Pub. 2002-10-10; prio. 2000-10-27 Family-cited Application pub., § 102(b)
R6 US 7,707,291 B2 (Nokia) Granted 2010-04-27; prio. 2005-02-01 Family-cited Patent, § 102(e)
R7 EP 1 961 153 B1 (Nokia Technologies) Granted 2019-02-20; prio. 2005-12-15 Family-cited Foreign pub., § 102(e)
R8 US 2006/0165060 A1 (Dua et al.) Pub. 2006-07-27; app. 11/040,847 IPR ground (not on face) Application pub., § 102(e)
R9 GlobalPlatform Card Specification v2.1.1 (Mar. 2003) Mar. 2003 IPR ground (not on face) Printed publication, § 102(b)
R10 Philips SmartMX P5CT072 controller spec (Oct. 2004) Oct. 2004 IPR ground (not on face) Printed publication, § 102(b)
R11 "Chan" (identity unconfirmed) ≤2021 IPR2021-00955 ground Printed pub., § 102(b)

Excluded deliberately: the "Cited By" lists (Wells Fargo, 2017–2026) and "Families Citing this family (49)" are later documents citing the '787. They are not prior art and I do not analyze them.


3. Reference-by-reference

R1 — US 6,031,912 A (Banksys)

Full citation: Banksys (BE), Process and device for permitting selective access to a security system, US 6,031,912 A; priority BE 9400813 dated 1994-09-09; PCT/BE95/00080 filed 1995-09-08; granted 2000-02-29. EP counterpart EP 0 780 012 A1 (pub. 1997-06-25).

Description (verified against the patent text): A security scheme for an electronic purse on a chip card. The payment system's terminal holds a "global" coded key K1; each card holds a derived key K2. On each transaction the terminal recomputes the card's supposed key from the global key and the card's identifying code using a one-way function and compares. To defeat counterfeit cards, the global key is renewed at intervals and the renewal is chained by an irreversible function F so the terminal can walk backwards through prior keys to authenticate stale cards. Explicitly names "electronic purse," "reloading terminal," "management centre," and key personalization at card issue.

§ 102 assessment — which claims does it potentially anticipate?

None as a whole. Anticipation requires a single reference to disclose every element arranged as claimed. R1 discloses no portable device with a smart card module, no emulator + e-purse applet pair, no NFC first interface, no second network interface, no midlet, and no two-security-channel personalization. Claims 1 and 11 (the only independents) are therefore not anticipated.

R1 is nonetheless § 103-relevant to a narrow set of limitations:

  • Claims 1 and 11 — the bare concept of an "e-purse" holding personalized keys used for authentication.
  • Claim 7 / 17 — "essential data being personalized include one or more operation keys": R1 discloses keys configured onto the card at issue.
  • Claims 6 and 16 — narrow background reading on key renewal vs. key personalization (R1's backward-chaining renewal is the opposite of the '787's forward install-then-protect-channel scheme, and a defendant should expect RFCyber to make that point).

Bottom line: weak, peripheral art. Realistically useful only as background/§ 103 filler. Its 1994 priority makes it § 102(b) art, so no § 102(e) date problems — but that is the only thing it has going for it.


R2 — US 2005/0222961 A1 (Staib) — the closest face citation

Full citation: Philippe Staib et al., System and method of facilitating contactless payment transactions across different payment systems using a common mobile device acting as a stored value device, US 2005/0222961 A1; app. 10/940,939 filed 2004-09-14; priority to provisional 60/559,818 filed 2004-04-05; published 2005-10-06. CPC: G07F 7/1008; G06Q 20/327; G06Q 20/3552; G06Q 20/382.

Description (verified): A mobile telephone (or PDA, key fob, watch) that acts as a stored-value / smart-card payment device. Key disclosures:

  • FIG. 2 device: CPU 14, memory 15 storing a mobile application 2 and the stored value (digital cash) in a secured area of memory 15; an NFC communication module 16 with its own processor for encryption and a secure memory area for storing the stored value; an antenna 18.
  • Alternative embodiment: an external secure module (e.g., USIM) in communication with the NFC module, storing the stored value in its own secure memory with its own processor and OS.
  • The mobile application emulates transmission standards and data exchange formats of payment systems it is not natively associated with.
  • Remote charge and recharge of stored value (FIGS. 8–9), i.e. funding over a network.
  • Credit card/PIN context; ISO/IEC 14443 discussion.

§ 102 assessment — which claims does it potentially anticipate?

None as a whole — but this is the reference that gets closest, and a defendant should treat it as the primary § 103 springboard.

Element-by-element against claim 1:

Claim 1 limitation In R2?
Portable device (cellphone) ✅ disclosed
Smart card module loaded in device ⚠️ partial — NFC chip 16 with own processor/secure memory; external secure module/USIM alternative
Emulator storing security values and updated transaction logs ❌ no "emulator" of a single-function card; no transaction-log updating
E-purse applet ❌ a "mobile application," not an installed smart-card applet
Both already personalized via a first security channel, keys stored in emulator ❌ no two-channel personalization architecture
Applet to transact with network server over a second security channel ❌
First interface NFC with a reader for e-commerce ✅ disclosed
Second interface for m-commerce with a payment server via an application ⚠️ remote recharge disclosed; "second security channel" not
Purse manager midlet as agent between applet and server ❌ a "mobile application," not a midlet-agent architecture

So: no anticipation of claims 1 or 11. Potentially relevant under § 103 to claims 1, 4, 11, 14 (NFC/tag interface, dual-interface device) and claims 5, 15 (network requests to a payment server). Note also R2 is the reference of record that Google used in its IPR2021-00955 (with Chan) — but only against claims 1, 2, 4–12, 14–19, and Google expressly did not challenge claims 3 and 13 (the Global Platform / MIFARE "transformed password" claims). That omission is informative: the petitioner apparently could not map the MIFARE-transformed-password limitation onto Staib.

Why R2 alone fails: the '787's novelty sits in the combination — a pre-personalized emulator + applet pair inside a smart card module, tied together by a two-channel (first/second) security architecture, with a midlet as the broker. R2 has none of the emulator/applet pair and none of the two-channel architecture. The IPR2022-00412 FWD is consistent with this: Apple lost on motivation to combine and on failure to disclose multiple limitations, and all 19 claims survived.


R3 — US 6,607,136 B1 (Atsmon et al. / BeepCard Inc.)

Full citation: Atsmon, Antebi, Lev, Cohen, Speyer, Sege, Altman, Anati, Physical presence digital authentication system, US 6,607,136 B1; assignee BeepCard Inc.; app. 09/570,399 filed 2000-05-12; granted 2003-08-19; earliest priority 1998-09-16.

Description (verified): An interactive authentication card that communicates with a PC/TV/radio via acoustic (audible/ultrasonic) and alternatively RF or magnetic signals, requiring no dedicated reader. Disclosure includes an E-Wallet system (FIGS. 29–30), one-button browser launch, form-fill, on-line authentication, challenge–response with digital certificates, a counter that increments per card press used for anti-replay, and — directly relevant here — personalization/activation on first use: "the issuer need not worry about programming the electronic card since the affiliation of the electronic card with the user's account would occur at the backend after the user has activated the card by pressing the card button. The personalization of the card occurs upon the 'first use' of the card."

§ 102 assessment:

No claim anticipated. R3 discloses card "personalization" only in the loose sense of associating a card ID with a user account — it does not disclose personalizing a smart-card applet and an emulator via security channels, does not disclose NFC, and does not disclose a purse-manager midlet.

§ 103-relevance is limited but real:

  • Claim 1 / 11 — "personalized" terminology; a defendant can argue the term was used loosely in the art pre-2006, supporting a broad construction or a § 112 indefiniteness attack on "personalized."
  • Claim 1 / 11 — the RF alternative embodiment in R3 (FIGS. 37–39) plus "card present" authentication touches the dual-interface idea, weakly.

Bottom line: background art. Its main value is evidentiary on claim construction, not invalidity.


R4 — CA 2305249 A1 (Sarcanin) — "Virtual safe"

Full citation: Branko Sarcanin, Virtual safe, CA 2305249 A1; filed 2000-04-14; published 2001-10-14.

Description: ⚠️ I could not retrieve the specification text within my search budget, and I will not characterize its disclosure from the title alone. "Virtual safe" in this era of the art generally refers to a virtual (server-side or software-emulated) secure container for payment credentials — which is thematically on point for the '787's emulator concept, but I cannot confirm that from the document.

§ 102 assessment: Cannot be assessed. I make no claim as to which (if any) of claims 1–19 it anticipates. Treat as unverified and pull the CA text before relying on it. It is § 102(b) art (published >1 yr before 2006-09-24) if it discloses anything relevant.


R5 — US 2002/0145632 A1 (Shmueli) — "Portable interface for computing"

Full citation: Shimon Shmueli et al., Portable interface for computing, US 2002/0145632 A1; priority 2000-10-27; published 2002-10-10.

Description: ⚠️ Not retrieved. On its title and date it concerns using a portable device as an interface to a computing resource.

§ 102 assessment: Cannot be assessed. Unverified. § 102(b) art.


R6 — US 7,707,291 B2 (Nokia) — "Handling incoming data"

Full citation: Nokia Corporation, Handling incoming data, US 7,707,291 B2; priority 2005-02-01; granted 2010-04-27.

Description: ⚠️ Not retrieved. Generic "handling incoming data" title; likely concerns messaging/data handling in a mobile terminal.

§ 102 assessment: Cannot be assessed. Unverified. If its priority is 2005-02-01, it is prior art under pre-AIA § 102(e) (U.S. filing before the 2006-09-24 priority date), which is worth noting because its grant date (2010) is after the '787's priority and would otherwise look non-citable. Do not assume it is not prior art merely because it issued in 2010.


R7 — EP 1 961 153 B1 (Nokia Technologies Oy)

Full citation: Nokia Technologies Oy, Method, device, and computer program product for network-based remote control over contactless secure storages; priority 2005-12-15; granted 2019-02-20.

Description: By its title, a method for remotely controlling contactless secure storage over a network from a device. This is the family-cited reference that maps most directly onto the '787's architecture — specifically:

  • Claim 1 / 11 — a first interface that is contactless ("contactless secure storages") and a second interface that reaches the same secure storage via a network — i.e., the exact e-commerce/m-commerce dual-path concept.
  • Claims 6 and 16 — "subsequent operations... conducted over the security channel" — remote control over a secure element implies a secured remote channel.

§ 102 assessment: With priority 2005-12-15, this predates the '787's 2006-09-24 date by ~9 months and is § 102(e)/§ 102(a) art (as an EP publication in the pre-AIA § 102(e) sense only if a corresponding U.S. filing exists — I could not confirm a U.S. sibling, so treat the § 102(e) route as unconfirmed and rely on § 102(a)/(b) publication-based routes instead).

No claim is anticipated as a whole (no emulator + applet pair, no midlet, no first-channel personalization). But of the family-cited references, R7 is the one I would pull first for a § 103 combination, because it independently discloses the "one secure storage reachable both contactlessly and over a network" architecture that is the heart of claim 1.


4. The art that actually matters — the IPR combination (R8–R10)

None of R1–R7 appears in any IPR ground. The combination the PTAB actually adjudicated was:

R8 — US 2006/0165060 A1 (Dua et al.)

Full citation: Dua et al., Method and apparatus for managing credentials through a wireless network, US 2006/0165060 A1; app. 11/040,847; published 2006-07-27. (Verified via Google Patents.)
Description: Credential/wallet management over a wireless network — a "wallet application" on a wireless device, credentials, and SIP-based remote management. Published 2006-07-27, i.e. ~2 months before the '787's 2006-09-24 priority date — so it qualifies as § 102(e) art with only a razor-thin margin. (Note: a pre-AIA § 102(e) reference takes its date from the U.S. filing date, so Dua's 2005 filing date helps the petitioner here.)
§ 102 assessment: Used only in § 103 combinations, never as a standalone § 102 reference, in IPR2021-00980 (Samsung) and IPR2022-00412 (Apple), against claims 1–19. It does not alone anticipate any claim — it lacks the emulator/applet/two-channel architecture.

R9 — GlobalPlatform Card Specification v2.1.1 (March 2003)

Printed publication, § 102(b). Supplies the card-manager / security-domain / three-3DES-key personalization framework that the '787's specification itself invokes (the spec recites the example keys 255/1/DES-ECB/404142…, 255/2/…, 255/3/…). Relied on for claims 1, 6–7, 11, 16–17 in the IPR combination.
§ 102 assessment: Anticipates nothing standing alone; it is a standards document disclosing mechanism, not the claimed device.

R10 — Philips SmartMX P5CT072 secure dual-interface PKI smart card controller specification (October 2004)

Printed publication, § 102(b). Supplies the dual-interface secure element hardware. Relied on for the "first interface / second interface" limitations of claims 1, 4, 11, 14.
§ 102 assessment: Anticipates nothing standing alone.

R11 — "Chan"

Named in the IPR2021-00955 ground as the secondary reference combined with Staib. ⚠️ I could not retrieve its full identity (publication number, assignee, date) and I will not guess. Unverified.

Critical outcome data for this combination: In IPR2022-00412, the Board (Scanlon, author) issued a Final Written Decision on 2023-07-18 determining that no challenged claims (1–19) were unpatentable — Apple failed on motivation to combine and on disclosure of multiple limitations. IPR certificate K1 effective 2024-03-29. The identical Dua-based combination was instituted twice (IPR2021-00980 and IPR2022-00412) and rejected on the merits once. But on the same day and on the same combination, the Board held all claims of sibling US 9,240,009 unpatentable (IPR2022-00413), affirmed by the Federal Circuit on 2025-08-14 (23-2418 opinion). The '787 survived only on its specific dual-interface / pre-personalized emulator + applet limitations.


5. Direct answer to the question asked

"For each of the '787's patent citations, which claim(s) does it potentially anticipate under 35 U.S.C. § 102?"

Answer: none of the cited references anticipates any of claims 1–19, and I found no reference — face-cited or IPR-cited — that does.

The reason is structural, not evidentiary: both independent claims (1 and 11) require the same four-element core — (i) an emulator in a smart card module storing security values and updated transaction logs; (ii) an e-purse applet; (iii) both already personalized via a personalization process built on a first security channel, with the applet configured to transact over a second security channel; and (iv) a purse manager midlet acting as agent. Every dependent claim adds to that core. No single reference of record discloses all four.

Where each reference does map (i.e., its § 103 role), consolidated:

Reference Claims to which its teachings are § 103-relevant
R1 Banksys 1, 6, 7, 11, 16, 17 (e-purse + personalized keys; background)
R2 Staib 1, 4, 5, 11, 14, 15 (closest face art: NFC device, secured stored value, remote funding, network requests)
R3 BeepCard 1, 11 (loose "personalization"; RF alternative)
R4 CA 2305249 unassessed — unverified
R5 US 2002/0145632 unassessed — unverified
R6 US 7,707,291 unassessed — unverified
R7 EP 1 961 153 1, 6, 11, 16 (contactless secure storage + network remote control)
R8 Dua 1–19 (as the § 103 primary reference — twice instituted, once rejected)
R9 GlobalPlatform 2.1.1 1, 6, 7, 11, 16, 17
R10 Philips SmartMX 1, 4, 11, 14

Which claims are hardest to invalidate: claims 3 and 13 (Global Platform + MIFARE data structures with "an appropriate transformed password based on the keys in the emulator"). Google did not challenge them in IPR2021-00955; Apple challenged them in IPR2022-00412 and lost. No reference of record discloses the MIFARE-transformed-password-from-access-keys limitation. Claims 6 and 16 (first channel = initial channel to an external SAM; second channel sitting on top of it) are the second-hardest, and are the locus of RFCyber's survival in the FWD.

Which claims to attack if you must: the patents-in-suit elections across this family have focused on claims 1, 2, 6, 8, 11 (RFCyber's E.D. Tex. election against Samsung) and on claim 1 in the 2024 Volkswagen/Electrify America complaint (Plug&Charge / ISO 15118). Those are the claims worth the effort; they are also the ones the Board has already examined.


6. Confidence and caveats

  • High confidence: the identity and content of R1 (Banksys) and R2 (Staib) — verified against their own full texts; the date and identity of R3 (BeepCard) and R8 (Dua); the content of R9/R10 as characterized in the IPR record; the fact that only two examiner citations appear on the '787's face; the IPR2022-00412 FWD outcome.
  • Moderate confidence: the characterization of R7 (EP 1 961 153) — drawn from its title/abstract rather than the full specification; the § 102(e) posture of R6 and R7 (which turns on unverified U.S. filing dates).
  • Low confidence / unverified — do not rely on: R4 (CA 2305249), R5 (US 2002/0145632), R6 (US 7,707,291) descriptions; the identity of R11 "Chan." I could not retrieve these within the search budget and have not guessed at their contents.
  • Explicit negative finding: I found no reference that anticipates any of claims 1–19. If your expectation was that the examiner-cited references anticipate specific claims, the correct result is the opposite, and I am flagging that rather than manufacturing an anticipation mapping.

Primary sources to re-verify: https://patents.google.com/patent/US9189787/en (face citations and family citations) · https://patents.google.com/patent/US6031912 (R1) · https://patents.google.com/patent/US20050222961 (R2) · https://patents.google.com/patent/US20060165060A1 (R8) · IPR2022-00412 Final Written Decision (2023-07-18).

Generated 9/28/2026, 5:21:35 PM

Obviousness

Combinations of prior art that suggest the claimed invention would have been obvious under 35 U.S.C. § 103.

✓ Generated

I'll ground the analysis in the prior-art references identified in the record before writing. Let me verify the key references.

Let me verify the Dua reference and the Board's motivation-to-combine reasoning.

Obviousness Analysis — US 9,189,787 B1 under 35 U.S.C. § 103

Patent: US 9,189,787 B1 ("the '787"), Method and apparatus for conducting e-commence and m-commence (title reproduced literally; "e-commence"/"m-commence" are the spellings on the face of the document and are not auto-corrected here).
App. No. 13/903,420 · filed 2013-05-28 · granted 2015-11-17 · effective priority 2006-09-24 (continuation of 13/400,038 → 11/534,653).
Claims analyzed: 1–19 (independents 1 and 11).

This section builds on the claim summaries, PTAB section, and litigation section already generated in this file. I do not repeat the claim text or the procedural history; where I cross-reference them I say so.


0. Source discipline and one flag

Per the operating rules, the full patent text supplied in this prompt is authoritative where it conflicts with search results. Two consequences:

  1. The "Prior Art" material on this page is of three different kinds and only two of them are citable art. Conflating them is the single most common error in this space, so I separate them in §2 below.
  2. ⚠️ Contradiction flagged (carried forward): the structured block in the earlier prompt asserted that the USPTO ODP returned no AIA trial proceedings for this patent. That is contradicted by the patent's own front page (three PTAB proceedings) and by the live records I re-pulled (Apple FWD, Samsung petition, Google petition). The prior section already overrode it; I rely on the patent front page and the retrieved decisions, not the ODP block.

Newly verified in this pass (live):

Item Verified content Source
Google's Ground 1 Staib (US 2005/0222961) in view of Chan (US 6,005,942), against claims 1–2, 4–12, 14–19 (i.e., not claims 3 and 13) IPR2021-00955 Petition & Gray Declaration
Google's exhibit set GOOG-1005 Staib; 1006 Holtmanns (US 7,628,322); 1007 Wentker (US 6,481,632); 1008 Chan (US 6,005,942); 1009 Pesonen (US 7,669,233); 1010 Lee (US 6,367,011); 1011 Rankl & Effing, Smart Card Handbook 3d ed. 2002; 1017 Yoshida, EE Times, Nov. 15, 2004; 1018 Philips MIFARE MF1 IC S70 Functional Spec v3.1 (Oct. 2002); 1019 PKI Note — Smart Cards Unified Patents IPR2021-00955 docket
Apple's Ground 1 Dua (US 2006/0165060 A1) in view of GlobalPlatform Card Spec v2.1.1 (Mar. 2003) and Philips SmartMX P5CT072 spec (Oct. 2004), claims 1–19 IPR2022-00412 Petition / Institution Decision
Chan's identity US 6,005,942, System and method for a multi-application smart card which can facilitate a post-issuance download of an application onto the smart card, Chan et al., assignee Visa International Service Association, filed Mar. 24, 1998, issued Dec. 21, 1999. Note: the PTAB exhibit list labels it "(GlobalPlatform Inc.)" — that label is the petitioner's shorthand; the face of the reference says Visa. I report both and harmonize neither. PTAB Ex. GOOG-1008
Dua's dates US 2006/0165060 A1, filed Jan. 21, 2005, published July 27, 2006, Robin Dua, Method and apparatus for managing credentials through a wireless network PTAB Ex. 1005
POSITA (as framed in the -00412/-00413 record) Degree in CS/CE/EE or equivalent + ~1 year professional experience in payment technology, which would have exposed the artisan to GlobalPlatform and smart cards RFCyber demonstratives, Ex. 2010

1. Governing law and the analytical frame

Pre-AIA § 103 applies. The '787 is a continuation whose every claim carries an effective filing date of 2006-09-24, i.e., before the AIA's 2013-03-16 first-inventor-to-file cutoff, so pre-AIA §§ 102/103 govern (AIA § 3(n)(1)). That matters twice over: it fixes the art date at 2006-09-24, and it fixes the statutory frame under which Dua is available (see §2.3).

The four Graham v. John Deere inquiries: (1) scope and content of the prior art; (2) differences between the prior art and the claims; (3) level of ordinary skill; (4) objective indicia. KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), governs the motivation/combination step and supplies the rationales in MPEP § 2143(A)–(G) that I apply in §4.

Critical framing fact: this is not a clean-slate § 103 question. The strongest articulated combination in the record — Apple's Dua + GlobalPlatform + Philips — was instituted on all 19 claims and then rejected on the merits (IPR2022-00412, FWD 2023-07-18: "no challenged claims unpatentable"). Any honest § 103 analysis must therefore do two things at once: (a) reconstruct why the claim set looks obvious on paper, and (b) explain precisely where the articulated combinations failed and what a materially stronger articulation would have to contain. I do both.


2. Scope and content of the prior art (segregated by legal weight)

2.1 On the face of the patent — examiner-cited (2 references)

Reference Identity What it supplies §102 status vs. 2006-09-24
US 6,031,912 (Banksys) Process and device for permitting selective access to a security system; priority 1994-09-09, issued 2000-02-29 Selective access to a security system via delivered keys; the "keys must be delivered to the reader for authentication" model that the '787's Background itself describes as the prior-art constraint §102(b) — issued >1 yr before
US 2005/0222961 A1 (Staib et al.) System and method of facilitating contactless payment transactions across different payment systems using a common mobile device acting as a stored value device; filed 2004-04-05, published 2005-10-06 A single mobile device acting as a stored-value device, contactless, across multiple payment systems — i.e., the "one portable device / one stored value / contactless commerce" premise §102(b) — published >1 yr before

Analytical note: the '787 carries only two cited references on its face. That is unusually thin for a 19-claim payment-card patent and is itself evidence that the examiner's search was narrow — a point that cuts against the patent when a defendant argues that better art exists outside the examined triangle.

2.2 Family-cited references (pre-2006; citable)

From the "Family Cites Families (5)" field — these were before the examiner during prosecution of the '218/'855/'787 family:

Reference Date Relevance to the '787 claims
US 6,607,136 B1 (Beepcard Inc.) 1998-09-16 / 2003-08-19 Physical-presence digital authentication; a portable token that authenticates by proximity to a reader — relevant to the NFC/"act as a tag" limitations (claims 4/14) and the "already personalized" state
CA 2305249 A1 (Branko Sarcanin) 2000-04-14 / 2001-10-14 Virtual safe — a personal security/credential container, the conceptual ancestor of a device-resident e-purse
US 2002/0145632 A1 (Shimon Shmueli) 2000-10-27 / 2002-10-10 Portable interface for computing — portable device as intermediary between a secure element and a network
US 7,707,291 B2 (Nokia) 2005-02-01 / 2010-04-27 Handling incoming data at a portable device; issued 2010 but filed before the '787 priority date → potential §102(e) art
EP 1961153 B1 (Nokia Technologies Oy) priority 2005-12-15 Network-based remote control over contactless secure storages — directly on point for the claimed "second interface… mobile commerce… against the fund stored in the emulator" (i.e., OTA/network control of a contactless secure store inside a handset)

These are all pre-2006 and therefore usable. EP 1961153 in particular has not, to my knowledge, been deployed against the '787 and is a plausible fresh secondary reference for the m-commerce-over-OTA limitation.

2.3 The substantive IPR art (the real § 103 arsenal)

Reference Date Role in the combinations
Dua, US 2006/0165060 A1 filed 2005-01-21; pub. 2006-07-27 Portable wireless device + wallet application (= claimed midlet); credential "extensions" for specific issuers (= claimed e-purse applet); RFID contactless path for subway/stored-value (= first interface); SIP/cellular path to an issuer/WCM server for credential issuance and OTA (= second interface). Available under pre-AIA §102(a) (published 2006-07-27, before the 2006-09-24 priority date) and §102(e) (US filing 2005-01-21).
GlobalPlatform Card Specification v2.1.1, Mar. 2003 Mar. 2003 Card manager; security domains each with three 3DES keys (the '787 spec quotes this verbatim); session-key derivation for a secure channel between card and host; personalization of applets via STORE DATA/PUT KEY; post-issuance install
Philips SmartMX P5CT072 Secure Dual Interface PKI Smart Card Controller Specification, Oct. 2004 Oct. 2004 Dual-interface secure controller with MIFARE emulation — i.e., a smart card module that emulates a single-functional MIFARE card and runs applets
Chan, US 6,005,942 issued 1999-12-21 Card domain + per-application security domains; post-issuance secure install; explicit application life-cycle states including "personalized"; keys managed per security domain
Philips MIFARE MF1 IC S70 Functional Spec v3.1, Oct. 2002 Oct. 2002 Express disclosure of MIFARE stored-value semantics: sector keys, value blocks, decrement/increment transactions. This is the reference that supplies "security values and updated transaction logs" in a document rather than via POSITA say-so.
Rankl & Effing, Smart Card Handbook 3d ed. 2002 2002 General-knowledge corroboration for personalization, key management, dual-interface cards
Yoshida, "Chip Makers Still Uncertain of Plunge into NFC," EE Times, Nov. 15, 2004 2004 NFC market/design-incentive evidence — useful for the motivation prong, not the disclosure prong
Holtmanns US 7,628,322; Wentker US 6,481,632; Pesonen US 7,669,233; Lee US 6,367,011; PKI Note — Smart Cards pre-2006 Secondary references assembled by Google for dependent-claim limitations (OTA provisioning, security domains, secure element key handling). I have not independently verified each one's disclosure in this pass — treat them as candidate secondary references pending verification.

⚠️ Essential negative finding. The remaining 49 "Families Citing this family" entries on this page — including Google's wallet cluster (US 8,335,921 / 8,357,274 / 8,646,059, priority 2010-12-17), NXP's "Method and device for installing and retrieving linked MIFARE applications" (CN 101965597B, 2008) and "NFC mobile communication device and NFC reader" (WO 2009/141764, 2008), NXP's "Method and trusted service manager for providing fast and secure access to applications on an IC card" (US 8,769,656, 2008), and Mastercard's "In-market personalization of payment devices" (US 9,172,539, 2011) — are all post-2006 and therefore NOT prior art to the '787's asserted 2006-09-24 priority date. They cannot support a § 103 rejection unless the priority date moves. See §7 for why that is the single highest-leverage lever in this file.


3. Element-by-element mapping — independent claims 1 and 11

I use the strongest documented mapping (Apple's Dua + GlobalPlatform + Philips), stated as a petitioner would state it, with the express-reference fix noted in the right column. Claim 11 is the method mirror of claim 1, so I chart claim 1 and note claim 11's additional phrasing at the end.

Claim 1 limitation (literal) Primary mapping Express-reference fix (to replace POSITA say-so)
Preamble: "A portable device for commerce" Dua's wireless device / mobile telephone running a wallet application —
[1a] "an emulator loaded in a smart card module for storing security values and updated transaction logs" Philips SmartMX P5CT072 as the smart card module, with its MIFARE emulation Add MIFARE MF1 IC S70 spec v3.1 (GOOG-1018) to show value blocks + transaction/decrement records express in the art; add Smart Card Handbook for dual-interface card architecture. Apple relied on POSITA knowledge here; the Board did not credit it (see §5.D).
[1b] "an e-purse applet to cause the portable device to function as an electronic purse (e-purse)" Dua's stored-value credential extension ("SVCE") for subway fare —
[1c-1] "both of the emulator and e-purse applet are already personalized via a personalization process built on a first security channel" GlobalPlatform v2.1.1 security-domain personalization: the applet is installed and personalized by the card manager under a security-domain session; Chan supplies the explicit life-cycle state "personalized" Chan is a patent, not a spec — it removes any public-accessibility attack on GlobalPlatform
[1c-2] "the emulator is set to store a set of keys for subsequent data access authentication" GlobalPlatform security-domain 3DES key sets; MIFARE sector keys written during personalization MIFARE S70 spec; the '787 spec itself admits the GP 3-key structure is standard (Key1/Key2/Key3 255/1,2,3/DES-ECB)
[1c-3] "the e-purse applet is configured to conduct a transaction with a network server over a second security channel" GlobalPlatform secure channel mechanics + Dua's WCM issuer server; second, distinct secure channel post-personalization Explicitly cite GP's data-structure/session-key chapters and the § on a security domain hierarchy (see §6 on claims 6/16)
[1d] "a first interface configured to perform field communication (NFC) with a reader to perform electronic commerce with the e-purse applet against a fund stored in the emulator" Dua's RFID/contactless interface to a reader/POS for subway stored-value MIFARE S70 (value blocks); Yoshida (NFC design incentives)
[1e] "a second interface configured to perform mobile commerce with a payment server via an application against the fund stored in the emulator" Dua's SIP/cellular path to the issuer/WCM for credential issuance and OTA value top-up EP 1961153 (Nokia: network-based remote control over contactless secure storages) is a direct-hit alternative here
[1f] "a purse manager midlet being executed in the portable device to act as an agent to facilitate communications between the e-purse applet and a payment server" Dua's wallet application —

Claim 11 recites the same elements as steps ("loading… personalizing… performing near field communication… performing mobile commerce…"), with one drafting difference worth noting: claim 1 says "field communication (NFC)" while claim 11 says "near field communication (NFC)." I reproduce each as written and do not harmonize them. The method claim's "wherein the application is executed in the portable device to act as an agent" is the method-side recitation of the midlet element [1f].

Preliminary conclusion on the independent claims. On the face of it, every element of claim 1 has a mapped disclosure in a pre-2006 reference. The obviousness case for claims 1 and 11 therefore turns entirely on (i) the motivation to combine and (ii) whether the "single fund, two channels, both already personalized" architecture is disclosed or merely assembled. That is exactly where the Board stopped Apple.


4. Motivation to combine — the KSR rationales, argued properly

The prior section recorded that Apple lost on motivation to combine. Below I articulate the rationales that a petitioner should use, keyed to MPEP § 2143, and then explain in §5 why the Board still rejected the ones Apple actually advanced.

4.1 Dua + GlobalPlatform (rationale: (C)/(F) — known technique improving a similar device; market/industry-standard forces)

  • Dua itself creates the motivation in express text. Dua's stated design premise is that its system and operating characteristics "are in conformance with the standards and other specific requirements of the chosen network or set of networks" and that credentials are issued by card organizations. Dua therefore directs the artisan implementing its WCM/issuer system to a card-organization standard. GlobalPlatform is the cross-industry standard for exactly that layer (card/application management and security). This is an express design incentive in the reference, not an after-the-fact "same field" assertion — which is the defect the Board identified in Apple's version.
  • The problem Dua leaves open is the problem GlobalPlatform solves. Dua discloses what to distribute (credentials) and through what pipe (SIP to the device), but is silent on the on-card architecture that lets multiple issuer credentials coexist under separate keys and be personalized to a compliant state. GlobalPlatform's security domains (three keys each) plus card manager supply precisely that. Rationale (C): using a known technique (GP security domains) to improve a similar device (Dua's multi-credential wallet) in the same way.
  • Predictability. GP v2.1.1 is a published specification with defined commands and a defined personalization flow; applying it to a JavaCard-class secure element yields predictable results. No undue experimentation. Rationale (A): combining known prior-art elements according to known methods to yield predictable results.

4.2 + Philips SmartMX / MIFARE (rationale: (B)/(D) — substitution of a known, ready-for-improvement component)

  • Dua expressly teaches integrating existing technology to "extend" the wallet application's capability and expressly contemplates subway stored-value cards that are organization-specific and the only accepted payment method. The transit stored-value function Dua describes is MIFARE's core market (the '787's own Background concedes MIFARE is "the most widely installed contactless smart card technology in the world," >500M ICs sold).
  • SmartMX P5CT072 is an off-the-shelf dual-interface secure controller with MIFARE emulation. Selecting it as "Dua's smart card" is a simple substitution of a known component for the function it was designed to perform — rationale (B) — and, alternatively, applying a known technique (MIFARE emulation inside a secure element) to a known device ready for improvement — rationale (D).
  • The "emulator" terminological bridge is supplied by the patent itself. The '787 defines "emulator" as "a hardware device or a program that pretends to be another particular device or program that other components expect to interact with." Under that definition, Philips's MIFARE emulation (hardware) and a software MIFARE emulator both read on the claim. This is a § 102/§ 103 claim-construction point, not a disclosure gap — and RFCyber's ability to distinguish hardware emulation would be weak given its own specification.

4.3 Staib + Chan (Google's Ground 1) — the alternative, and the untested one

  • Staib supplies the device premise with unusual precision: a common mobile device acting as a stored value device, performing contactless transactions, across different payment systems. That is claim 1's preamble + [1d] + the "fund stored in the emulator" concept in a single reference — and it is already of record on the '787's face, which forecloses any argument that it is non-analogous art.
  • Chan supplies the security/personalization architecture. Chan discloses a card domain + per-application security domains that each manage keys, post-issuance secure install, and an application life cycle that runs to an express "personalized" state. Chan is the Visa/GlobalPlatform antecedent — it is, in substance, the GlobalPlatform security-domain model in patent form.
  • Motivation (rationale (C) + (E)). Staib's whole premise is multiple payment systems on one device. The immediate engineering problem Staib creates is: how do you install, key, and separate multiple payment applications on one already-issued card without one issuer's keys exposing another's? Chan is addressed to that exact problem, in the same field, for the same class of device. A POSITA seeking to implement Staib would have found Chan/GlobalPlatform obvious to try and would have had a reasonable expectation of success because both are key-management frameworks for multi-application smart cards.
  • Strategic significance: this ground was never adjudicated — IPR2021-00955 settled pre-institution, so the Staib + Chan combination has no adverse merits ruling against it, unlike Dua + GlobalPlatform + Philips.

4.4 The cross-over combination: Staib + GlobalPlatform + Philips (and Dua + Chan + Philips)

Because Google's and Apple's art sets do not overlap on the primary reference, a petitioner can mix them: Staib (device/stored value/contactless) + GlobalPlatform or Chan (security domains/personalization) + Philips or the MIFARE S70 spec (emulator/keys/logs). This is the combination I regard as the strongest realistic § 103 theory on the current record, for three reasons:

  1. It replaces Apple's weakest link (Dua for the smart-card architecture) with Chan, a patent whose disclosures of "card domain," "security domain," "key management," and "personalized" are express and documentary.
  2. It replaces Apple's reliance on inherent POSITA knowledge for the MIFARE emulator with the MIFARE MF1 IC S70 functional specification — a pre-2006 printed publication that expressly shows value blocks and key-based access.
  3. It stacks three independent motivations (Dua/Staib design incentives; GP industry-standard practice; MIFARE's dominance in transit) rather than resting on one.

5. Where the articulated combinations actually failed — and why it matters

This is the part that most § 103 write-ups omit, and omitting it makes the analysis worthless here. RFCyber's Patent Owner Response in IPR2022-00412 attacked the combination under seven headings. Reproducing the headings verbatim from the docket (they are the Board's operative issues):

PO heading (verbatim) The gap What a stronger petition must add
"A POSITA Would Not Combine Dua with GlobalPlatform" / "Apple Does Not Set Forth a Motivation To Combine" Apple's motivation was conclusory; the Board was not persuaded that Dua's standards-compliance language directed an artisan to GP for the on-card architecture Cite Dua's own text requiring conformance to card-organization standards and tie it to a specific GP mechanism (security domain creation, PUT KEY, STORE DATA) — show the hole in Dua that GP fills
"Apple Identifies No Motivation to Combine Philips with Dua (with or without GlobalPlatform)" No articulated reason for SmartMX specifically Use Dua's own "integrate existing technology to extend capability" and the transit-stored-value passage; add Yoshida for market pull toward NFC dual-interface hardware
"Does Not Render Obvious 'an emulator loaded in a smart card module for storing security values and updated transaction logs'" Apple relied on what a POSITA "knew" about MIFARE Substitute the MIFARE MF1 IC S70 Functional Spec v3.1 — express value blocks + keys + transaction records
"Does Not Render Obvious 'wherein both… already personalized…'" as required by all challenged claims The claim requires the completed personalization state to pre-exist, with the emulator holding keys and the applet configured for a second channel Chan's express "personalized" life-cycle state + GP's post-personalization applet channel. Note: this limitation sits in every claim, so it is the case-dispositive one
"Does Not Render Obvious… 'a personalization process built on a first security channel so that the emulator is set to store a set of keys… and the e-purse applet is configured to conduct a transaction… over a second security channel'" Two distinct, ordered channels GP security-domain session (channel 1) → applet's own keys/channel to backend (channel 2); Chan's per-application security domain makes the layering express
"Apple Fails to Show that 'a second interface configured to perform mobile commerce with a payment server via an application against the fund stored in the emulator'… Would Be Obvious" (claims 1–10 and 11–19) The same fund must be spent over both interfaces EP 1961153 (Nokia) — network-based remote control over a contactless secure storage in a handset — is the cleanest missing piece in the record
"Apple's Combination Does Not Render Obvious Claims 6 and 16" The "security channel on top of the initial security channel" architecture GP 2.1.1's security-domain hierarchy/supplementary domain treatment + Chan's card-domain-over-application-domain structure

Judgment: the FWD held all 19 claims not unpatentable. That is a real, adverse, merits ruling. It is not binding on a non-privy defendant, but it is powerful § 282 evidence and a near-certain trigger for discretionary denial arguments. Any § 103 theory that merely re-ran the same three references with better rhetoric would likely lose for the same reason.

Why the dependent claims were not a separate safe harbour. Apple challenged 1–19, including claims 2–10 and 12–19. So there is no un-adjudicated dependent claim to fall back on (contrast Google, which pointedly excluded claims 3 and 13 from its Staib + Chan ground — the two claims that recite the Global Platform / MIFARE "transformed password" subject matter). Claims 3 and 13 are therefore the only claims never challenged on the Dua-based theory, yet they were challenged and survived in Apple's IPR. Net effect: every claim of the '787 has been tested and none canceled.


6. Dependent-claim obviousness (claims 2–10, 12–19)

Because claim 1 is the crux, the dependents add modest incremental disclosure. Charted against the strongest combination (Staib/Dua + Chan/GlobalPlatform + Philips/MIFARE S70):

Claim(s) Added limitation Doctrine Supplemental reference
2 / 12 "security module configured to install and personalize the e-purse applet via either the first interface or the second interface," keys updated when the first-channel personalization completes Rationale (A): predictable result of GP/Chan card-domain install; "keys updated on completion" is Chan's PUT KEY / state-advance to PERSONALIZED Chan § card domain + security domain; GP PUT KEY
3 / 13 e-purse "built on top of a global platform" to access MIFARE data structures with an appropriate transformed password based on the emulator keys Rationale (A)+(C): GP-on-JavaCard is the standard deployment; "transformed password" is the '787's own P2P key-transformation step (see the '787's FIG. 3C at 362), and key-transform-for-legacy-access is a routine security step GlobalPlatform v2.1.1 + MIFARE MF1 IC S70 spec. Note: claims 3/13 were not challenged by Google and RFCyber's own spec recites the GP key structure verbatim — but Apple did challenge them and lost, so this is a hard road.
4 / 14 first interface is RFID; device acts as a tag read by a reader attached to an Internet-connected computer Rationale (B): substitution of a known contactless interface into Staib's contactless stored-value phone Staib; Beepcard US 6,607,136 (proximity-authenticating portable token)
5 / 15 web agent on the computing device interacts with the RFID reader and the network server; composes network requests (e.g., HTTP) Rationale (C): a known client/server split — thin reader-side agent + backend composition — applied to the e-commerce path US 2002/0145632 (Shmueli) (portable interface between secure element and network); general HTTP client/server art of record via Smart Card Handbook
6 / 16 layered channels: initial channel to install/personalize the applet with an external SAM, then a channel "on top of" it protecting subsequent operations, "wherein any subsequent operation is conducted over the security channel via the e-purse applet" Rationale (A): GP security-domain hierarchy (issuer SD → supplementary/application SD) and Chan's card-domain/security-domain nesting produce exactly this layering; this is the limitation the Board found Apple did not reach GP v2.1.1 (SD hierarchy) + Chan (card domain managing per-application security domains). Highest-difficulty dependent limitation in the set.
7 / 17 personalized data = operation keys (load, purchase), default PINs, administration keys (unblock/reload PIN keys), MIFARE passwords Rationale (A): these are the ordinary contents of a payment-applet personalization payload GP v2.1.1 load/personalization data; MIFARE S70 keys; Chan key management. Note the '787's KEY1/2/3 3DES values are GP's own published defaults — an admission of standard-practice content
8 / 18 smart card module part of the portable device (embedded) Alternative-form recitation Philips SmartMX (embedded secure element in handset)
9 / 19 smart card module is an external device inserted into the portable device Alternative-form recitation; economically the same invention in SIM/SD form factor Smart Card Handbook (SIM/plug-in card form factors); Staib
10 purse manager midlet configured to access the emulator directly Rationale (B): direct on-card access from the wallet app — a design choice between the applet-mediated path and direct emulator access Dua's wallet application; Chan (application command interface to the card domain)

Note on claim-10 asymmetry: the "direct emulator access" limitation appears only in the apparatus claim set (claim 10). Claim 11's method set has no counterpart (it ends at claim 19 with the internal/external module alternatives). There is therefore no method-side claim 20; do not infer one.


7. The highest-leverage lever: the priority date

Everything above assumes the 2006-09-24 priority date holds. It is contestable, and if it is lost, the § 103 landscape changes completely and for the worse (for the patent).

  • The '787 is a continuation, so it can claim the 2006-09-24 date only for subject matter supported by the 11/534,653 disclosure. Claim 1/11 recite a dual-interface (NFC + network) architecture, an "emulator loaded in a smart card module" that is pre-personalized with keys and transaction logs, and a "purse manager midlet" — all of which a challenger can argue are described only at a level of generality in the 2006 disclosure. If any claim is not entitled to 2006-09-24, AIA § 102/§ 103 applies and the art window opens to 2013.
  • What that unlocks is on this very page. The 49 "Families Citing this family" entries — all post-2006 — become citable, including the ones that read almost directly on the survival limitations identified in §5:
  • CN 101965597B / NXP — "Method and device for installing and retrieving linked MIFARE applications" (2008) → the emulator + applet linkage ([1a]–[1b]).
  • WO 2009/141764 / NXP — "NFC mobile communication device and NFC reader" (2008) → the first interface + tag role ([1d], claims 4/14).
  • US 8,769,656 / NXP — "Method and trusted service manager for providing fast and secure access to applications on an IC card" (2008) → secure channel + personalization ([1c]).
  • Google's wallet cluster — US 8,335,921 "Writing application data to a secure element," US 8,357,274 "Local trusted services manager for a contactless smart card," US 8,646,059 "Wallet application for interacting with a secure element application without a trusted server for authentication" (priority 2010-12-17) → the midlet-as-agent limitation ([1f]) directly.
  • US 9,172,539 / Mastercard — "In-market personalization of payment devices" (2011) → the "already personalized" limitation ([1c]) sitting in every claim.
  • US 2012/0130838 — "Method and apparatus for personalizing secure elements in mobile devices" (2012) → personalization process + keys.
  • This is the correct strategic conclusion: on the 2006 date the claim set is a hard § 103 target (and has already beaten one full IPR). On a 2013 date the same claim set is a comparatively easy § 103 target. A challenger should therefore run priority as a § 103 case, not as a side issue — because losing priority converts a strong patent into a weak one twenty times over.

Caveat: a continuation cannot add new matter, and the '787's specification is (so far as the record shows) the same disclosure as the parents. I have not performed a limitation-by-limitation § 112 written-description audit of the 11/534,653 disclosure against claim 1 of the '787 in this pass. The priority-loss theory is plausible and high-value, but unverified — treat it as a thesis to test, not a conclusion.


8. Objective indicia (Graham factor 4)

The record I can reach contains no evidence of nexus-backed objective indicia — no unexpected results, no commercial-success-with-nexus, no copying, no licensing-due-to-merit evidence. The three IPRs turned on disclosure and motivation, not on secondary considerations. Two observations:

  • That is a defensive weakness for the patent owner going forward: the '787's non-obviousness case, in the record, rests on the absence of a motivation to combine plus disclosure gaps — both of which are attackable with better art and better articulation.
  • Conversely, the FWD itself functions as a strong piece of quasi-objective evidence for RFCyber: a full merits adjudication by an expert tribunal, on all 19 claims, found the best-articulated combination insufficient. Expect a district court to weigh that heavily, and expect RFCyber to lead with it.

9. Bottom line

Strongest combination on the current record — my ranked assessment:

# Combination Rationales Strength Why
1 Staib + GlobalPlatform (or Chan) + Philips SmartMX / MIFARE S70 (A), (B), (C), (D) Moderate–high as a theory; untested Staib supplies the stored-value/contactless/multi-system portable device (of record on the '787's own face); Chan/GP supplies security domains + personalization + "personalized" state; the MIFARE S70 spec supplies the emulator's value blocks, keys and transaction records expressly — curing the exact POSITA-say-so defect that sank Apple
2 Dua + GlobalPlatform + Philips (as filed) (A), (C), (F) Low–moderate; adjudicated and REJECTED Institution on all 19 claims, then FWD of no unpatentability; the motivation and the "single fund / two channels / already personalized" gaps were decisive
3 Staib + Chan (Google's Ground 1) (C), (E) Moderate; untested — settled pre-institution Clean, two-reference, patent-only ground with no adverse ruling; the weakness is that neither reference expressly discloses the pre-personalized dual-channel emulator+applet architecture
4 Dua + GP + Philips + EP 1961153 (Nokia) (A), (B), (C) Moderate; adds the missing piece EP 1961153 is a direct hit on "network-based remote control over a contactless secure storage" — i.e., the second interface spending the same fund
5 Whatever becomes available if priority moves to 2013 (NXP MIFARE-linking, NXP TSM, NXP NFC device, Google secure-element wallet cluster, Mastercard in-market personalization) (A)–(F) High, if priority fails These references map onto the very limitations that survived the IPRs

The candid verdict. Under § 103, the claims of the '787 are not airtight — every element has a pre-2006 documentary home, the patent's own specification concedes that MIFARE, GlobalPlatform, and its Key1/Key2/Key3 3DES structure are industry practice, and the face-of-patent art is thin. But the best-articulated combination has already been tried and lost (IPR2022-00412, FWD 2023-07-18, all 19 claims sustained), and the surviving claim core — one smart card module, one fund, a pre-personalized MIFARE emulator holding keys and transaction logs, and an e-purse applet configured to spend that same fund over both an NFC path and a network path under a layered two-channel security architecture — is genuinely narrow. The realistic § 103 path is not a re-run of Dua; it is (i) a cross-over combination that swaps the smart-card-architecture reference (Chan or GP) and the emulator evidence (MIFARE S70) into the device reference that best fits the claim (Staib), or (ii) an attack on the 2006 priority date that unlocks the four NXP references, the three Google secure-element references, and Mastercard's in-market personalization — all of which sit on this page's forward-citation list and all of which read on the limitations that proved fatal to Apple.


10. Confidence and open items

  • High confidence: the identities and dates of Dua, Chan, Staib, GlobalPlatform v2.1.1, the Philips SmartMX P5CT072 spec, and the MIFARE MF1 IC S70 spec v3.1; Google's Ground 1 = Staib + Chan on claims 1–2, 4–12, 14–19; Apple's Ground 1 = Dua + GP + Philips on claims 1–19; the FWD outcome.
  • Moderate confidence: the precise legal significance of each PO-response heading as reflected through the FWD's reasoning (I am reading PO's framing of the issues, which is adverse advocacy, alongside the judgment line and the institution decision); the pre-2006 citable status of US 7,707,291 and EP 1961153 (dates taken from the Google Patents family-cites field, not independently verified against the references themselves).
  • Not verified — do not treat as settled: the contents of Holtmanns US 7,628,322, Wentker US 6,481,632, Pesonen US 7,669,233, Lee US 6,367,011 and PKI Note — Smart Cards; the § 112/written-description support in the 11/534,653 disclosure for the '787's dual-interface and pre-personalization limitations; and whether the '787's "e-commence / m-commence" title variants create any claim-construction or CDX issue (they should not — the title is not limiting).
  • Explicitly negative finding: I found no reference in the record that expressly discloses a single MIFARE purse funded over both an NFC reader path and an OTA/network path as one integrated pre-personalized element. That is the '787's actual point of novelty, and it is why the Dua combination failed. The closest candidates are EP 1961153 (network remote control of a contactless secure storage) and the Philips SmartMX dual-interface architecture — neither of which was put in the same petition.

Sources (primary): https://patents.google.com/patent/US9189787/en (patent text, claims, cited/citing references) · IPR2021-00955 Petition and Gray Declaration (Staib + Chan ground; exhibit list) · IPR2021-00980 Petition (Dua + GlobalPlatform + Philips ground) · IPR2022-00412 FWD · IPR2022-00412 Institution Decision · RFCyber PO Response and demonstratives (Ex. 2010) · Google Patents US 2006/0165060 A1 (Dua) · US 6,005,942 (Chan).

Generated 9/28/2026, 5:22:20 PM

Extensions

Patent term adjustments, term extensions, continuations, divisionals, family members, and expiration dates.

Not generated yet. Click Generate to call the active LLM provider with the configured prompt.

Derivative works

Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.

Not generated yet. Click Generate to call the active LLM provider with the configured prompt.

Keep exploring

More patents asserted by RFCyber Corp.

Other patents in Financial Technology (FT)

See all Financial Technology (FT) patents →

This patent in court (8)

8 tracked lawsuits name US 9189787.