Invalidity dossier

US 11317279

Client, computing platform, and methods for conducting secure transactions

Current assignee: Certus Technology Systems Inc

Added 9/29/2026, 7:31:50 AM

At a glanceNo PTAB challengesNo litigation on fileFinancial 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 search for authoritative information on this specific patent, including any litigation activity.

The initial searches returned irrelevant results. Let me try more targeted queries.

Let me search for litigation activity involving this patent and its owner.

I was able to retrieve the authoritative patent document and confirm bibliographic data from Google Patents, the USPTO-hosted patent PDF (patentimages.storage.googleapis.com), and FreePatentsOnline. I could not find any Court of Appeals for the Federal Circuit (CAFC) 2026 docket, PTAB proceeding, or district-court action naming U.S. Patent No. 11,317,279 specifically. Details and caveats below.


US 11,317,279 B2 — Bibliographic Summary

Field Value
Patent number US 11,317,279 B2 (interpreted literally as "11,317,279")
Title Client, computing platform, and methods for conducting secure transactions
Application number US 14/293,112
Pre-grant publication US 2016/0073263 A1 (published 2016-03-10)
Inventor Jack Wolosewicz
Assignee Certus Technology Systems, Inc. (assignment of interest from Jack Wolosewicz recorded 2022-03-08; REEL/FRAME 059200/0802)
Filing date 2014-06-02
Priority date 2012-08-13 (claims benefit of U.S. App. 13/964,593 filed 2013-08-12, which claims benefit of U.S. Provisional 61/682,530 filed 2012-08-13)
Issue date 2022-04-26
Adjusted expiration 2034-08-06 (legal-status listing; not a legal conclusion)
Claims 11 total (independent claims 1 and 7)
Examiner Yonas A. Bayou (Primary Examiner)
Attorney/agent STLG Law Firm; Soody Tronson
Family members EP 3183701 B1, PL 3183701 T3, WO 2015187533 A1, ES 2830387 T3

Abstract (as issued): "The present invention is generally related to client and computing platforms that may be used for conducting secure transactions."

Source grounding: https://patents.google.com/patent/US11317279/en ; https://patentimages.storage.googleapis.com/70/06/24/44a76d87b1b393/US11317279.pdf ; https://www.freepatentsonline.com/y2016/0073263.html


Plain-Language Overview of the Independent Claims

Claim 1 — Method for providing enhanced security during a secure transaction. A user's client device is offered, and accepts, an option on its display to securely connect to a receiving device (one tied to an e-commerce website) over a short-range / near-field communication path ("first communication path"), while the client device is separately connected to the cloud via an Internet interface ("second communication path"). In response to accepting the option, an authoritative server generates an authenticating single-use token that is (a) encoded with an error-control code and (b) time-limited to less than approximately three minutes. The client device receives the token and then transmits it out loud through its speakers as an audible audio signal ("third communication path"), where a microphone on the receiving device picks it up. The receiving device relays the token back to the authoritative server over a "fourth communication path," the server compares the token it generated with the token it got back, and on that basis verifies the client device's identity so the e-commerce transaction can proceed. All four communication paths are used before the transaction itself.

Claim 7 — System for making secure transactions. A three-party system: (i) a client device with a near-field interface (first path), a wireless interface (second path), and an audible audio transmission interface (third path); (ii) a receiving device with a near-field interface, a wireless interface, an Internet interface (fourth path), and an audible audio reception interface; and (iii) an authoritative server in wireless communication with both. The server includes a single-use token generator producing a token time-limited to less than approximately three minutes, an interface to convey the token encoded with an error-control code to the client, and a processor configured to (a) trigger transmission of the token as an audible signal from the client's speakers to the receiving device's microphone, (b) obtain the relayed token back from the receiving device, and (c) authenticate by comparing the originally transmitted token with the token obtained from the receiving device. Again, all four paths are used before the transaction.

Dependent claims (brief): Claims 2–6 add conducting the transaction over the Internet, authenticating the client at the server upon acceptance, biometric authentication (retinal scan, palm print, voice print, keyword annunciation, thumbprint), and the client/receiving devices being laptops, desktops, or smartphones running a browser. Claims 8–11 add approving on a match, denying on a mismatch, and performing a mathematical operation (addition, subtraction, convolution, comparison, correlation, or combinations) to establish a match.

Technical gist: A passwordless, single-use-token authentication scheme in which a server-generated, error-corrected, short-lived token travels from a phone (via audible sound) into a nearby browser-equipped device, which relays it back to the server for a match — the acoustic channel being the mechanism that proves physical human presence (positioned as a replacement for CAPTCHA and as a defense against man-in-the-middle replay).


Litigation / Post-Grant Activity — Important Caveat

I did not locate any CAFC 2026 docket entry, PTAB petition, IPR, PGR, or district-court complaint naming US 11,317,279 specifically.

Two cautions under the strict "do not auto-correct / interpret identifiers literally" rule:

  1. Search results surfaced PTAB matters involving PGR2023-00012 (Patent 11,328,286 B2) and IPR2025-00712 (Patent 11,393,279 B2). These are different patents with different numbers and are not US 11,317,279. I am deliberately not conflating them. (Note in particular that "11,393,279" and "11,317,279" are distinct identifiers — the IPR2025-00712 petition concerns a gaming/prize-redemption patent, not this secure-transactions patent.)

  2. Google Patents' "Cited By" list for US 11,317,279 shows only later-issued patents (e.g., US 11,416,859 B2 to Eckoh UK; BlackBerry V2X certificate families; US 11,695,772 B1 to Capital One), i.e., forward citations — not litigation.

Uncertainty statement: I have high confidence in the bibliographic data and claim summary above because they come from the authoritative patent text and USPTO-hosted PDF. I have low confidence regarding any 2026 CAFC or district-court docket activity for this specific number — I found none, but my search tooling returned no CAFC docket index, so absence of results here is not affirmative proof that no such proceeding exists. To verify definitively, the appropriate sources would be PACER/RECAP, the CAFC docket search, and Docket Navigator — none of which returned indexed results for "11317279" in my searches. If you need a certified litigation history, I'd recommend a direct PACER/RECAP docket query rather than relying on this summary.

Generated 9/29/2026, 10:52:07 AM

Cases on file (0)

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

No cases on file mention this patent. Upload a CSV or add a case manually in Admin → Manage litigation cases.

Litigation summary

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

✓ Generated

I'll search for litigation involving US patent 11317279 across patent litigation trackers and court sources.

Let me search more targeted litigation databases and plaintiff-specific queries.

Let me check the Unified Patents litigation portal and other docket sources directly.

Result: No litigation found involving US Patent No. 11,317,279

I searched for litigation specifically naming US 11,317,279 B2 ("Client, computing platform, and methods for conducting secure transactions," current assignee Certus Technology Systems, Inc., inventor Jack Wolosewicz). I could not identify any court case — in any jurisdiction — in which this patent is asserted or challenged (no infringement suit, no declaratory judgment action, no IPR/PGR, and no PTAB proceeding).

Because I hit the tool's step limit, I want to be precise about what I actually searched and why the negative is reliable but not exhaustive:

Sources queried

  • General litigation-targeted queries: US patent 11317279 litigation, "11317279" patent lawsuit
  • Assignee-targeted queries: Certus Technology Systems Inc patent litigation lawsuit defendant, "Certus Technology Systems" v. district court case number patent infringement
  • Docket-targeted queries: "11317279" OR "11,317,279" courtlistener docket
  • A Unified Patents litigation portal query (portal.unifiedpatents.com litigagation 11317279) — note this last query was truncated by hitting the step limit, so I could not complete the Unified Patents / PACER cross-check as thoroughly as I intended. This is the main gap in my search.

False positives I ruled out (not litigation for this patent)

Context from the patent record (Google Patents)

  • The Google Patents page for US 11,317,279 shows no litigation section and no listed court proceedings; its "Cited By," "Families Citing," and "Also Published As" tables list only other patents/publications, not lawsuits.
  • Legal status: Active, adjusted expiration 2034-08-06; a maintenance-fee reminder was mailed 2025-12-15.
  • Related family members that could be asserted in parallel: EP 3183701 B1, WO 2015187533 A1, ES 2830387 T3, PL 3183701 T3. I found no litigation on those either.

Bottom line

Based on the sources I was able to reach, there is no known litigation involving US 11,317,279. I cannot state this with 100% certainty because (a) very recent filings (e.g., weeks old) may not yet be indexed in the sources my queries surfaced, and (b) I was unable to complete a full PACER/Unified Patents docket sweep before hitting the search limit.

Recommended verification steps (which I'd run if given more queries):

  1. Directly query Unified Patents Litigation Portal (https://portal.unifiedpatents.com/litigation) and its patent-detail page for 11,317,279.
  2. Search Docket Navigator / Lex Machina and PACER for "11,317,279" as patent-in-suit.
  3. Search the USPTO PTAB (PTAB Center / PTAB API) for IPR/PGR/CBM petitions naming 11,317,279.

If you'd like, I can run those three targeted queries next.

Generated 9/29/2026, 10:52:18 AM

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.

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 canonical "no PTAB activity" result against web sources before finalizing.

Let me run a couple more targeted checks for assertions/appeals involving this patent and its owner.

PTAB Proceedings Analysis — U.S. Patent No. 11,317,279 B2

Verification note: The structured "PTAB proceedings on file" block states the USPTO Open Data Portal returns no AIA trial proceedings for this patent. I ran independent web searches (PTAB E2E / PTABTS, PTAB-focused aggregators, and Federal Circuit / litigation feeds) to test that default and found nothing for US 11,317,279. The searches did surface two numerically adjacent patents that are different patents belonging to different owners — flagged below so no one conflates them.


Proceedings overview

Total AIA trial proceedings on US 11,317,279: 0 — zero active, zero claims invalidated, zero claims sustained, zero settled, zero institution denials; the patent is wholly untested at the PTAB, so all 11 claims (including independents 1 and 7) remain presumptively valid and no § 315(e) estoppel attaches to anyone. Defensive posture: this is not a "hardened" patent (nothing has survived anything) — it is an unchallenged patent, which cuts both ways for a defendant: you get a clean § 311–§ 319 runway with no estoppel and no FWD claim-construction record against you, but you also forfeit the free "claims are already canceled" argument and must build the invalidity case from scratch.

⚠️ Contradiction check against the prior sections: none. The earlier summary already flagged that IPR2025-00712 concerns 11,393,279, not this patent. My searches confirm that disambiguation: IPR2025-00712 is Activision Blizzard, Inc. v. Milestone Entertainment, LLC, on U.S. Patent No. 11,393,279 B2 (a gaming/prize-redemption patent), filed 2025-03-26, instituted 2025-10-16. It has no relationship to Certus Technology Systems or the secure-transactions patent. Do not cite it in any brief about 11,317,279.


No proceedings to report

There are no ### {PROCEEDING_NUMBER} sections to populate because the canonical list is empty. To make the absence auditable, here is what I affirmatively checked and what I found:

Search vector Result
USPTO ODP / PTAB structured data (per prompt) No AIA trial proceedings
PTAB proceeding search for "11,317,279" / "11317279" No hits
PTAB search for assignee Certus Technology Systems No AIA trial against this patent. (Certus appears in the citation graph as the owner of the later-issued US 11,444,940 B2, "User authentication of smart speaker system" — a forward citation, not a PTAB case.)
District-court assertion (which would start the § 315(b) clock) No complaint naming 11,317,279 located
Federal Circuit / appeal feeds No appeal referencing this patent number

Near-miss identifiers — explicitly distinguished (do not auto-correct these):

  • IPR2025-00712 — U.S. Patent No. 11,393,279 B2 (Activision Blizzard v. Milestone Entertainment). Challenged claims 1, 3–9, 13, 17, 18, 23, 25, 26, 28, 29 over Kelly, Walker, Schneier; instituted 2025-10-16. Different patent, different patent owner, different field. Not relevant.
  • PGR2023-00012 — U.S. Patent No. 11,328,286 B2. Also a different number (carried over from the earlier section). Not relevant.

Sources consulted for the near-miss disambiguation: https://ai-lab.exparte.com/case/ptab/IPR2025-00712/activision-blizzard-inc-v-milestone-entertainment-llc and https://ipverse.greyb.com/ptab-web/cases/case-details/IPR2025-00712.


Strategic summary

Claim status. All 11 claims of US 11,317,279 are UNTESTED — none canceled, none confirmed by the Board, none amended. Independent claim 1 (method: near-field option → authoritative-server single-use token with error-control coding, time-limited to less than ~3 minutes → audible speaker-to-microphone relay → server-side comparison) and independent claim 7 (the three-party system claim covering the same four communication paths) stand exactly as issued 2022-04-26. Every dependent claim (2–6, 8–11) also stands. There is no FWD to quote and no claim-level disposition to report.

Estoppel landscape. Because no IPR/PGR was ever instituted, there is no § 315(e)(2) estoppel and no § 325(e)(2) PGR estoppel anywhere. A defendant today may raise any § 102/§ 103 ground on any patent or printed-publication art, and may also litigate § 101 and § 112 in district court without IPR-estoppel risk. The only practical constraint is the § 315(b) one-year bar, which is not yet triggered because I found no service of an infringement complaint on any party. Two additional levers worth pricing: (i) the § 325(d) discretion risk if you recycle art already of record — the face of this patent cites, among others, WO 2005/011191 (Qualcomm, "Digital authentication over acoustic channel"), WO 2001/058080 (Beepcard), WO 2012/106380 (Hill, "Sonic based digital networking"), US 2014/0068272 (Vasco, acoustic token input), US 5,668,876 (Ericsson) and US 5,136,644 (Telecash) — so the acoustic-channel authentication concept was squarely before the examiner and a doctrine-of-§ 325(d) "same art, same arguments" denial is a live risk if you build on those references; (ii) the Fintiv / § 314(a) discretionary-denial overlay given the Director's workload-management memos.

Pattern signals. None of the usual patterns are present: no repeat petitioner, no Unified Patents or other defensive aggregator, no PTAB appeal history by this patent owner, no IPR-vs-district-court parallel track. The patent has never been asserted in a located litigation, which is consistent with the absence of IPRs — PTAB challenges overwhelmingly follow assertion. Note also the prosecution wrinkle in the legal-events log: the application went abandoned 2020-12-21 (failure to respond), was revived 2021-05-26 via a granted maintenance-fee/petition event, and then issued after a Notice of Allowance 2022-01-13 — i.e., the claims as issued were reached on a fourth round of prosecution after multiple final rejections. That procedural history is worth pulling from the file wrapper if you petition, because the claim language that squeezed past the examiner (the "time limited to less than approximately three minutes" and "error control code" limitations) is where the art-mapping fight will live.


Recommended next steps

  • No PTAB activity exists — say so plainly, and use it. There is no FWD to link and no canceled claim to lean on. Your invalidity case is built from zero, but it is built without estoppel and without an adverse Board claim construction. If you are a defendant weighing an IPR, the strategic calculus is entirely offensive: you would be the first challenger and would set the claim-construction record for the "four communication paths," "audible audio signal," and "time limited to less than approximately three minutes" limitations.
  • Confirm the § 315(b) clock yourself before filing. Because my search tooling found no complaint, I cannot state affirmatively that none exists. Before relying on "no bar," run a direct PACER/RECAP docket query and Docket Navigator for assignments of 11,317,279 and for Certus Technology Systems — a served-but-unindexed complaint would start the one-year clock and could also supply Fintiv / § 314(a) discretionary-denial ammunition for the patent owner if parallel litigation is advanced.
  • Round out the record. Pull the full file wrapper (USPTO Patent Center, application 14/293,112) to map exactly which references and arguments were traversed during the 2018–2021 prosecution — this is what drives your § 325(d) exposure analysis. Also check for any EPO opposition to the family member EP 3183701 B1, since the same prior art often surfaces there first and is a cheap source of claim-construction positions.
  • Milestone/deadline note (if you do file): there are no pending milestones to track today. Once you file an IPR, the statutory clock is fixed — institution decision due within 6 months of petition, and FWD within 12 months of institution (35 U.S.C. §§ 314(b), 316(a)(11)) — with any appeal going to the Federal Circuit under § 319.

Uncertainty statement: I have high confidence in the "zero AIA proceedings" conclusion as of 2026-09-29, because it is the canonical USPTO ODP result and was corroborated by independent web searches of PTAB dockets and aggregators. I have lower confidence in the completeness of my litigation search — my tooling has no direct PACER/RECAP index, so absence of a located complaint is not affirmative proof that none was served. Verify with PACER/RECAP or Docket Navigator before relying on the § 315(b) analysis above.

Generated 9/29/2026, 10:52:29 AM

Ownership chain (1)

Asserters network →

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

  1. 2022-03-08 · reel 059200/0802 · Assignment

    WOLOSEWICZ, JACKCERTUS TECHNOLOGY SYSTEMS, INC.

    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 research the assignment record and the assignee's business history.

Let me verify the assignment record and the assignee's current status.

I hit the tool's step limit mid-research, so I'll flag exactly what I could and could not verify.

Inventors

Inventor Address of record Employer at filing (determinable)
Jack Wolosewicz (sole named inventor) San Francisco, CA Certus Technology Systems, Inc. — he was the founder and CTO of Certus, which he founded in early 2013, i.e., before the 2014-06-02 filing of this application (the Betaboston/Boston Globe profile of 2014-04-06 describes him as "Certus's chief technology officer, who founded the company in early 2013").

Unusual-pattern check: Only one inventor, and he is the founder/CTO of the assignee — no multi-inventor team to track for departures. However, there is a notable chronological oddity: Wolosewicz left Certus to co-found Cyberus Labs in July 2016 (Crunchbase: "Cyberus Labs — Co-Founder, CEO, and CTO, Jul 2016"; prior role listed as "Certus, Founder & CTO"). So the founder departed the assignee roughly two years after this application was filed and roughly six years before it issued. That is not the classic "all inventors depart within 12 months of filing" fire-sale precursor, but it does mean the patent issued to a company whose founder had already moved to a new venture (Cyberus Labs, whose "Cyberus Key" product is a password-free one-time-audio-token authentication platform — the same technical lane as this patent).


Original assignee

Certus Technology Systems, Inc. (San Francisco, CA) — the "Original Assignee" and "Current Assignee" listed on the face of the issued patent.

  • Primary line of business: passwordless authentication via acoustic/near-field signaling. Per the 2014 Boston Globe/Betaboston report: "The basic idea is that a smartphone can serve as a high-tech authentication device, communicating with your laptop or tablet using high-frequency sound waves… Every time you log into a site, we're generating a unique, one-time-use password that only exists for a split second. It's a kind of sound fingerprint that your smartphone creates and the other device hears." (https://www.bostonglobe.com/business/2014/04/06/highlights-from-betaboston/WxuAPYTeX4CmLcGCRRkEqL/story.html)
  • Did they ship a product embodying the claims? This is the strongest pro-operating-company fact in the record. The described product — a smartphone that emits a short-lived one-time credential as an audible sound wave picked up by a nearby laptop/tablet/terminal — maps directly onto independent claim 1's "transmitting, via an audible audio signal… the authenticating single-use token via speakers of a client device" and the receiving device's "microphone." At the time of the article, Certus "ha[d] raised about $375,000 in seed funding from individual investors and [wa]s conducting its first pilot test," with ~4 employees in Boston and 2 in San Francisco. So: an early-stage startup with a pilot, not a mass-market shipping product.
  • Current status: Unclear / not confirmed. I did not complete a California Secretary of State entity-status lookup before hitting the step limit, and I found no evidence of acquisition, dissolution, or bankruptcy. What I can say from the record: the patent owner is still recorded as a small entity (the USPTO legal-events entry "MAINTENANCE FEE REMINDER MAILED… ENTITY STATUS OF PATENT OWNER: SMALL ENTITY," 2025-12-15), and — per the previously generated sections — no litigation naming this patent was found. Certus's founder subsequently built a successor-generation product at Cyberus Labs, but no recorded assignment moves this patent to Cyberus Labs (see below). Treat "Certus is still the operating owner" as my best reading of the record, not a verified corporate-registry conclusion.

Assignment timeline

There is exactly one assignment recorded against US 11,317,279 in the sources I could reach (Google Patents legal events; the corresponding USPTO Assignment Center record I could not open directly before the step limit).

  • 2022-03-08 (executed) / recorded 2022-03-08 — Reel 059200 / Frame 0802
    • Conveyance: Assignment (Assignment of Assignors Interest)
    • Assignor: WOLOSEWICZ, JACK
    • Assignee: CERTUS TECHNOLOGY SYSTEMS, INC. (a California corporation)
    • Correspondent: Not retrieved. I could not pull the recording correspondent (the attorney/firm who filed the recordation) from the Assignment Center entry before the step limit. I am deliberately not substituting the patent's prosecution counsel — STLG Law Firm / Soody Tronson, listed on the printed patent as "Attorney, Agent, or Firm" — for the assignment correspondent; those are different roles and I have no source tying STLG to the recordation.
    • Context: Internal reorg / late chain-of-title cleanup. This is an inventor-to-company confirmatory assignment executed ~7 years 9 months after the 2014-06-02 filing, only ~7 weeks before the 2022-04-26 grant. A founder executing an assignment to his own company this late in prosecution typically signals a re-execution of a missing or unrecorded original assignment (e.g., the original paperwork for the 13/964,593 parent didn't carry over) rather than a transfer of ownership to a third party.

No post-issuance assignment exists in the record. The patent has been owned by Certus Technology Systems, Inc. from (effective) 2022-03-08 through issuance (2022-04-26) to the present, with no subsequent Reel/Frame conveying or encumbering it that I could locate. There is no security agreement, license, merger, change-of-name, or release on record for this number in the data I retrieved.

Caveat on the caveat: the previously generated sections noted my assignment search that surfaced unrelated reel-like strings (e.g., a "059200" hit that turned out to be a genetic-sequencing PDF, not a USPTO reel). The 059200/0802 reel/frame above comes specifically from the Google Patents legal-events table for US 11,317,279, and I am reproducing it literally. It was not independently confirmed against the Assignment Center UI.


Timeline diagram

timeline
    title Ownership of US 11317279
    2012 : Priority date
    2014 : Application filed by Certus
    2016 : Pre-grant publication
    2022 : Wolosewicz assigns to Certus
         : Patent issued to Certus

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT. The only transfer is from the individual inventor to his own operating startup (Reel 059200/0802, 2022-03-08). There is no "IP / Patents / Licensing / Holdings / Ventures" successor, no Delaware/Texas single-member LLC, and no registered-agent-service address in the chain. The assignee is a named California corporation.

2. Known asserter in the chain — NOT PRESENT. Current and only assignee is Certus Technology Systems, Inc., which does not match any entity on the referenced NPE lists (Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, Spangenberg entities). No RPX/Unified "high-frequency plaintiff" match surfaced.

3. Repeat correspondent across the chain — UNCLEAR / INSUFFICIENT DATA. There is only one link in the chain, so "recurrence" is definitionally unassessable. Critically, I could not retrieve the assignment-record correspondent at all. The patent's face lists prosecution counsel STLG Law Firm; Soody Tronson — that is a single appearance in a different capacity (prosecution, not recordation) and is not a finding of repeat NPE filing by that firm.

4. Cascading transfers — NOT PRESENT. Zero post-issuance transfers; no chained LLCs; nothing to sequence within 24 months.

5. Pre-litigation transfer — NOT PRESENT (and moot). The previously generated sections found no infringement suit naming this patent, so there is no litigation date to measure a "within 6 months before suit" transfer against.

6. Bankruptcy fire-sale — NOT PRESENT. No evidence of a Certus Chapter 7/11 filing or of patents being sold in a bankruptcy proceeding.

7. Privateering — NOT PRESENT. No operating-company-to-NPE transfer exists to evaluate. The founder's later move to Cyberus Labs is a personal new venture, not a recorded transfer of this patent, and no assertion activity by Cyberus Labs against Certus-lineage patents surfaced.

8. Defensive aggregator — NOT PRESENT. The chain does not terminate at RPX, AST, LOT, Unified, or OIN. It terminates at the operating assignee.


Verdict

Insufficient data (only the original assignment).

The entire recorded ownership history of US 11,317,279 is a single inventor-to-employer assignment — Reel 059200/0802, executed and recorded 2022-03-08 — from sole inventor Jack Wolosewicz to Certus Technology Systems, Inc., the same entity that is both "Original Assignee" and "Current Assignee" on the issued patent (granted 2022-04-26). There are no post-issuance assignments, no shell LLCs, no known-asserter assignee, and no bankruptcy or defensive-aggregator endpoint; the assignee is a founder-owned, small-entity startup that publicly described a pilot product (smartphone-emitted acoustic one-time credential) mapping onto claim 1's audible-audio token path. Under the assignment criteria, a chain consisting of only the original assignment is categorized Insufficient data — there is insufficient ownership activity to support an NPE finding, which is itself the meaningful result: no NPE pattern is present on the face of the assignment record.

Verification link: https://assignment.uspto.gov/patent/index.html (search patent number 11317279; confirm Reel 059200 / Frame 0802 and capture the assignment correspondent, which I could not retrieve). Cross-check the patent detail at https://patents.google.com/patent/US11317279/en.

Explicit gaps I could not close before hitting the step limit (do not treat as negative findings): (a) the assignment correspondent on Reel 059200/0802; (b) direct confirmation of the Assignment Center entry against Google Patents; (c) California SOS entity status for Certus Technology Systems, Inc.; (d) any SEC filings (Certus appears to be private, so likely none).

Generated 9/29/2026, 10:52:44 AM

Prior art

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

✓ Generated

I'll search for details on the key prior-art references cited against this patent, focusing on the ones most relevant to the claimed acoustic near-field token transmission and server-side comparison.

Prior-Art Analysis for US 11,317,279 B2

Building on the earlier sections. The bibliographic record, claim summary, and litigation findings from the prior sections stand. This section does not repeat them; it addresses only the requested prior-art mapping. One cross-reference note: the earlier summary states the priority date "2012-08-13 (claims benefit of U.S. App. 13/964,593 filed 2013-08-12, which claims benefit of U.S. Provisional 61/682,530 filed 2012-08-13)" — that is consistent with the authoritative text, and it drives the § 102 date analysis below.

USPTO identifier check. US 11,317,279 B2 corresponds to application US 14/293,112, filed 2014-06-02, titled "Client, computing platform, and methods for conducting secure transactions," inventor Jack Wolosewicz, assignee Certus Technology Systems, Inc. (Grounding: https://patents.google.com/patent/US11317279/en.) The reference list below is the prosecution "Citations (17)" set shown for this exact number.


A. Threshold § 102 framework (read this before the table)

Two facts control which of the 17 references can even be anticipatory art:

  1. The claimed priority date is 2012-08-13, but the operative AIA "effective filing date" for the issued claims is contestable. This is a continuation-in-part. Under AIA § 102, a reference must predate the effective filing date of the claimed invention. If the issued independent claims (e.g., the "time limited to less than approximately three minutes" and error-control-coded-token limitations) contain new matter not supported in the 2012-08-13 provisional or the 2013-08-12 parent, the effective filing date for those claims collapses to 2014-06-02.

  2. That distinction changes the art status of the 2014-dated references. Several citations here (notably the Vasco publication) fall between 2012-08-13 and 2014-06-02. They are prior art only in the second scenario.

Also applying: anticipation under § 102 requires a single reference disclosing every claimed element. On my reading, no single cited reference discloses all elements of claim 1 or claim 7. The references are therefore best characterized as § 102 references for sub-combinations and as § 103 (obviousness) references in combination. I flag this explicitly rather than implying clean single-reference anticipation.


B. The 17 cited references — citation, dates, description, potential § 102 mapping

Tier 1 — Directly on-point to the acoustic-token core

1. WO 2005/011191 A1 — Qualcomm Incorporated — "Digital authentication over acoustic channel"

  • Filing/priority: priority US 10/625,710 filed 2003-07-22; PCT/US2004/023579 filed 2004-07-21; published 2005-02-03.
  • Family: US 7,487,362 B2; US 8,391,480 B2 (continuation, filed 2009-02-03, granted 2013-03-05); CN 1842989 A. (https://patents.google.com/patent/WO2005011191A1/en ; https://patentimages.storage.googleapis.com/10/ef/87/bf98569c423d5d/US8391480.pdf)
  • Description: A token stores a cryptographic key and generates an access code using the key (optionally combined with a time element from a clock); a converter turns the access code into sound waves; an audio output unit outputs the acoustic signal. A verifier device has an audio input unit that receives the sound, recovers the access code, generates a second access code, and grants authentication if the two codes correspond. Multi-carrier/BPSK modulation with interleaving is used.
  • Potential § 102 mapping: Discloses the acoustic transport of an authenticating code from a first device's speaker to a second device's microphone, plus a verifier-side comparison — i.e., the acoustic loop and verification recitation in claim 1 and the audio-transmission/audio-reception/compare architecture of claim 7. The clock/time-element teaching is relevant to the "time limited" limitation; the interleaving/multi-carrier robustness is relevant to the "encoded using an error control code" limitation.
  • Anticipation gap: the code is generated by the token holder's device (or via a challenge), not by an "authoritative server" that generates and conveys the token to a client that then holds it; there is no e-commerce-website receiving device relaying over a distinct "fourth communication path." Strongly material, but I would map it as a sub-combination / § 103 reference for claims 1 and 7, not a clean § 102 anticipator.

2. WO 2001/058080 A1 — Beepcard Incorporated — "Physical presence digital authentication system (transactions and authentication)"

  • Filing/priority: priority US 60/180,530 filed 2000-02-07; PCT/US2001/003881; published 2001-08-09.
  • Family (US counterpart): US 6,607,136 B1 (granted 2003-08-19) and continuations such as US 7,706,838 B2. (https://uspto.report/patent/grant/[7706838](/patent/7706838))
  • Description: An electronic card transmits and receives data via sound waves (audible or ultrasonic) to/from a base station (TV, radio, PC). Stated tasks include authenticating a user at a website and completing a sales transaction at a website, using the conventional PC sound system (microphone/speaker); challenge-response schemes and an authentication server are described.
  • Potential § 102 mapping: Discloses the acoustic device↔computer channel, a receiving device with a microphone, relay of data to an authenticating server, and website/e-commerce authentication — i.e., the acoustic-path and receiving-device elements of claim 1, and the audio-transmission/reception interfaces of claim 7. Broad support for claims 5–6 (PC/laptop/handheld running a browser).
  • Anticipation gap: the code/token originates at the card via its own key/counter, not a server-generated single-use token; no explicit error-control-code encoding or <~3-minute time limit; the four-path architecture is absent. Best treated as a highly relevant § 103 reference, potentially anticipatory if combined art supplies the server-generated single-use token.

3. US 2014/0068272 A1 — Vasco Data Security, Inc. — "Strong authentication token with acoustic data input over multiple carrier frequencies"

  • Filing/published: filed 2012-08-30; published 2014-03-06 (granted as US 9,184,915 B2; related US 8,930,702 B2, family priority to US provisional 61/446,779 filed 2011-02-25). (https://patents.google.com/patent/US20140068272 ; https://www.freepatentsonline.com/[9184915](/patent/9184915).html)
  • Description: A strong-authentication token with an acoustic input interface; a PC/tablet/smartphone emits a modulated acoustic signal encoding input data that the token demodulates, using multiple carrier frequencies, and handling multipath/resonance distortion. The signaling is described as effectively one-way from the computing device to the token.
  • Potential § 102 mapping: Discloses an acoustic data channel between a computing device and a receiving token, with distortion/error handling — relevant to the acoustic-transport and error-control elements of claim 1 and the audio interfaces of claim 7.
  • Anticipation gap / date caveat: the direction is reversed relative to claim 1 (PC speaker → token microphone, not client speaker → receiving-device microphone), and the "token" is a dedicated authentication token, not the claimed client. Critically, this reference is the most date-sensitive: published 2014-03-06, only ~3 months before this patent's actual 2014-06-02 filing. If the claims are entitled only to 2014-06-02 (CIP new matter), this is § 102(a)(1) art; if full 2012-08-13 priority holds, it is not § 102 art. Reverse-direction teaching → best mapped as § 103.

Tier 2 — Authentication / comparison / payment context (mostly § 103)

4. US 5,668,876 A — Telefonaktiebolaget LM Ericsson — "User authentication method and apparatus"

  • Filed/priority 1994-06-24; granted 1997-09-16. (https://patents.google.com/patent/US5668876 ; https://uspto.report/patent/grant/[5668876](/patent/5668876))
  • Description: A user accesses an electronic service; a challenge code goes to a separate personal unit; a PIN activates a response code; an authentication center compares the received response with the expected response and informs the service node (authenticated/not). Also cited in the background of the Vasco references.
  • Potential § 102 mapping: Directly discloses the server-side (authentication-center) comparison of a received value against an expected value to authenticate a user for access to an electronic service — relevant to the "comparing, by the authoritative server" and "verifying an identity" steps of claim 1 and the server comparison of claim 7 (and claims 8–9).
  • Anticipation gap: no acoustic channel, no server-generated single-use token conveyed to a client, no e-commerce receiving device. § 103 reference.

5–7. US 2007/0233615 A1; US 2007/0244811 A1; US 2007/0255662 A1 — Obopay Inc.

  • Filed/priority 2006-03-30; published 2007-10-04 / 2007-10-18 / 2007-11-01 respectively.
  • Descriptions: (i) "Member-Supported Mobile Payment System"; (ii) "Mobile Client Application for Mobile Payments"; (iii) "Authenticating Wireless Person-to-Person Money Transfers."
  • Potential § 102 mapping: Relevant to the mobile/person-to-person transfer scenario described in this patent's specification and to authenticating wireless money transfers — i.e., context for claim 1 (secure transaction) and claim 7 (system for secure transactions), and the P2P use case.
  • Anticipation gap: no acoustic near-field token loop, no server-generated error-coded single-use token. § 103/background.

Tier 3 — Peripheral / background references (weak or non-anticipatory)

8. US 5,136,644 A — Telecash — "Portable electronic device for use in conjunction with a screen"

  • Filed 1988-04-21; granted 1992-08-04.
  • Description: Portable electronic token for interaction with a screen (an early optical/display-based data-input token; repeatedly cited in the Vasco family background as a Digipass-type optical token).
  • § 102 mapping: Tangential. It supports the general concept of a personal token supplying authentication data to a computer, but discloses no acoustic path, no server-generated single-use token, no comparison architecture. Background only; not anticipatory of claims 1 or 7.

9. US 2003/0204726 A1 — Kefford, Mark Gregory — "Methods and systems for secure transmission of information using a mobile device"

  • Filed 2002-04-25; published 2003-10-30.
  • Description: Secure transmission of information using a mobile device.
  • § 102 mapping: General mobile-device secure-transaction context. No acoustic token loop or server-generated single-use token. Background/§ 103.

10. US 2004/0153649 A1 — Rhoads, Geoffrey B. — "Digital authentication with digital and analog documents"

  • Priority 1995-07-27; published 2004-08-05.
  • Description: Steganographic/watermark-based authentication of documents (Digimarc line).
  • § 102 mapping: Unrelated to the acoustic near-field token architecture. Background only.

11. US 9,195,980 B2 — Nokia Technologies Oy — "Method and apparatus for recovery during authentication"

  • Filed 2009-10-30; granted 2015-11-24.
  • Description: Authentication-recovery methodology.
  • § 102 mapping: Marginal. Relevant only to resilience/recovery aspects of authentication; discloses none of the acoustic-transport or four-path elements. Background/§ 103.

12. US 10,659,421 B2 — Seven Networks, LLC — "Messaging centre for forwarding e-mail"

  • Priority 2004-11-22; granted 2020-05-19.
  • Description: E-mail forwarding in a mobile messaging centre.
  • § 102 mapping: Date-qualifies as prior art but is subject-matter unrelated; no acoustic token or server comparison. Background only.

Tier 4 — Post-dating references (NOT § 102 art; flagged for completeness)

These appear in the citation set but cannot be § 102 prior art for these claims, because their effective dates post-date even the 2014-06-02 actual filing. I list them so the set is complete, and so their presence is not mistaken for anticipatory art.

Ref Assignee / Title Priority Granted Why not § 102 art
US 9,516,487 B2 Visa Int'l — "Automated account provisioning" 2013-11-19 2016-12-06 Post-2012; § 102(a)(2)-eligible only if effective filing = 2014-06-02 (then marginally), but disclosed subject matter (provisioning) does not meet claims 1/7
US 9,680,942 B2 Visa Int'l — "Data verification using access device" 2014-05-01 2017-06-13 Post-2012; possible § 102(a)(2) only under the 2014-06-02 scenario; no acoustic/server-token teaching
US 10,277,576 B1 Syniverse Technologies — "Diameter end-to-end security with a multiway handshake" 2017-06-29 2019-04-30 Post-dates filing; not § 102 art
US 10,484,345 B2 Visa Int'l — "System and method for identity verification across mobile applications" 2014-07-31 2019-11-19 Post-dates 2014-06-02 filing; not § 102 art
US 10,664,844 B2 Visa Int'l — "Unique code for token verification" 2015-12-04 2020-05-26 Post-dates filing; not § 102 art

(Two of these — US 9,516,487 and US 9,680,942 — become § 102(a)(2) "effectively filed before" art only in the 2014-06-02 effective-filing-date scenario, and even then their disclosures do not appear to reach the acoustic/four-path limitations.)


C. Bottom line on the most relevant prior art

The three references that actually matter for this patent's inventive core are:

  1. WO 2005/011191 A1 (Qualcomm, 2003-07-22 / pub. 2005-02-03) — the closest single teaching of acoustic transmission of an authentication code + verifier-side comparison + time element + coded/robust modulation.
  2. WO 2001/058080 A1 (Beepcard, priority 2000-02-07 / pub. 2001-08-09; US counterpart US 6,607,136 B1 / US 7,706,838 B2) — the closest teaching of an acoustic card↔computer interaction used to authenticate at, and transact with, a website, through the PC's own microphone/speaker and an authentication server.
  3. US 2014/0068272 A1 (Vasco, filed 2012-08-30 / pub. 2014-03-06) — an acoustic data-input channel with error/distortion handling, but in the reverse direction and with date-sensitivity to the CIP's effective filing date.

Best § 102 (anticipation) candidates, viewed narrowly:

  • For the acoustic speaker→microphone token delivery + server/verifier comparison limitations of claim 1 (and the audio interfaces of claim 7): WO 2005/011191 A1 (Qualcomm) is the strongest.
  • For the server-side comparison / verify-identity step (claims 1, 7, 8, 9): US 5,668,876 A (Ericsson).
  • For the acoustic card-to-computer website authentication/transaction context (claims 1, 5–7): WO 2001/058080 A1 (Beepcard).

Realistic assessment: Because claim 1 requires the combination of (a) a server-generated single-use token, (b) error-control-coded, (c) <~3-minute time-limited, (d) delivered by near-field option and then (e) audible speaker→microphone to a separate e-commerce receiving device that relays it over (f) a distinct fourth path for server comparison — no cited reference discloses all elements. Nothing in this set anticipates claims 1 or 7 outright; the Tier-1 references are properly § 103 material, most plausibly combined as Qualcomm (acoustic token + verification) + Beepcard (card↔PC website authentication) + Ericsson (server-side comparison), with the server-side single-use-token generation and time-limit limitations being the disputed features.


D. Caveats (stated plainly, per operating rules)

Generated 9/29/2026, 10:53:27 AM

Obviousness

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

✓ Generated

I'll verify the key prior-art references from the patent's citation list before building the obviousness analysis.

Obviousness Analysis — U.S. Patent No. 11,317,279 B2 Under 35 U.S.C. § 103

Analyst work-product. This builds on the earlier-generated bibliographic summary, claim summary, and litigation summary in this file and does not repeat them. It is a technical § 103 assessment, not a legal opinion or a freedom-to-operate/validity opinion. Where I relied on publicly retrievable reference text I give the URL; where I relied only on the patent's own citation table I say so.


0. Scope, ground rules, and two flagged caveats

Rule compliance. I have interpreted all identifiers literally — e.g., US 11,317,279 B2, US 2014/0068272 A1, WO 2012/106380 A1, WO 01/58080 A1, WO 2005/011191 A1, US 5,668,876 — and have not auto-corrected them. As previously noted in this file, IPR2025-00712 (Patent 11,393,279 B2) and PGR2023-00012 (Patent 11,328,286 B2) are different patents and are not conflated here.

Caveat 1 — I analyzed the art the patent itself cites. The task directs me to "[u]se the results from the Prior Art section of this page." I therefore built the combinations primarily from the 17 examiner-cited references and the 6 "Family Cites Families" references listed on the Google Patents page (https://patents.google.com/patent/US11317279/en), supplemented by US 9,098,691 B2 — a same-family sibling of a cited reference (see §5, note 3) — and CN 104769622 A. A full § 103 attack would also sweep art the examiner never cited; that is outside this brief.

Caveat 2 — I have not read the prosecution history. The Legal Events on Google Patents show this application was abandoned (2020-12-21), revived by petition (2021-05-26), twice given Final Rejection (2020-06-05; 2021-11-03), and then allowed (2022-01-13). That pattern is a strong signal that one or both of the two narrowest claim limitations — "encoded using an error control code" and "time limited to less than approximately three minutes" (Claim 1) — were added or narrowed by amendment to overcome art. That matters twice over:

  1. It suggests the applicant itself conceded that a broader claim covering error-coded acoustic tokens was not patentably distinct from the cited art.
  2. If those limitations were added in the 2014-06-02 application (or the 2013-08-12 CIP), the priority claim to the 2012-08-13 provisional may not cover the issued claims, which would move the effective filing date forward and make additional references prior art. I explore this in §2.

Sources consulted. Beepcard: https://patents.google.com/patent/WO2001058080A1 and https://uspto.report/patent/grant/[7706838](/patent/7706838) · Qualcomm: https://patents.google.com/patent/WO2005011191A1/en and https://patents.google.com/patent/[US8391480](/patent/US8391480) · Vasco: https://patents.google.com/patent/US20140068272 and https://patentimages.storage.googleapis.com/48/0b/8e/9f43fca3a154d2/US20140068272A1.pdf · Vasco sibling: https://patentimages.storage.googleapis.com/7c/c2/92/a252a1d422bd68/US9098691.pdf · Hill: https://patents.google.com/patent/WO2012106380A1/en.


1. Governing framework

Under Graham v. John Deere Co., 383 U.S. 1 (1966) and KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), I assess: (a) scope and content of the prior art; (b) differences between the prior art and the claims; (c) level of ordinary skill; and (d) secondary considerations. Under KSR, a combination is obvious not only where the art contains an express "teaching, suggestion, or motivation," but also where the combination is of known elements performing known functions yielding predictable results, or where it would be "obvious to try" a finite number of identified, predictable solutions with a reasonable expectation of success. MPEP § 2143 lists the acceptable rationales I invoke below: (i) combining prior art elements according to known methods; (ii) simple substitution of one known element for another; (iii) use of a known technique to improve similar devices in the same way; (iv) applying a known technique to a known device ready for improvement; and (v) "obvious to try."

Claims 1 and 7 are effectively coextensive (method vs. system recitation of the same four-path architecture), so any combination that renders Claim 1 obvious renders Claim 7 obvious, and vice versa.


2. Effective filing date — and why it may not matter much

Document Date Note
Provisional 61/682,530 2012-08-13 Google Patents "Priority date"
CIP parent 13/964,593 2013-08-12 Google: "Continuation-In-Part"
Application 14/293,112 2014-06-02 Filing date
Issued claims 2022-04-26 Issue

An issued claim is entitled to the provisional date only for subject matter supported by the provisional. The two limitations that most look like late narrowing amendments — an error control code on the token and a <~3 minute lifetime — are discussed in the issued specification, but the specification's own disclosure of token lifetime is loose: it says a token "may 'survive' … a fraction of a second," "a few seconds, or, perhaps as long as a few minutes or a longer period of time," while elsewhere the patent says both tokens "must be used within, for example, one half second or less." A claim bounded at "less than approximately three minutes" is thus a range-selection from a disclosure that reaches "a longer period of time" — an invitation to a § 112(a) written-description challenge and, in parallel, to a priority challenge.

Why this matters for § 103. If the effective filing date is 2013-08-12 or 2014-06-02 rather than 2012-08-13, then Vasco's US 2014/0068272 A1 (US filing 2012-08-30, provisional 61/446,779 filed 2011-02-25) and Vasco's US 9,098,691 B2 (US filing 2012-02-24, same 2011-02-25 provisional) are unambiguous prior art under § 102(a)(2)/102(e). Even on the 2012-08-13 date, I explain below why Vasco and Hill are still available.

Constraint on the analysis: several cited references postdate every plausible effective filing date and are therefore not § 102 prior art on the face of the record — Visa's US 9,516,487 (2013-11-19), US 9,680,942 (2014-05-01), US 10,484,345 (2014-07-31), US 10,664,844 (2015-12-04); Syniverse's US 10,277,576 (2017-06-29); and Seven Networks' US 10,659,421, which predates (2004-11-22) but is directed to messaging-center e-mail forwarding — technically available, substantively irrelevant. I do not rely on them.


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

A POSITA here would hold a bachelor's degree in electrical engineering or computer science (or equivalent) with 2–4 years of experience in network security, authentication, or payment systems, and would be familiar with: (a) one-time-password (OTP) and challenge-response authentication; (b) short-range data transport including audio/near-ultrasonic signaling, inductive coupling, and NFC; (c) web/e-commerce session flows; and (d) error-detection and error-correction coding (parity, CRC, Hamming, Reed-Solomon). This is a routine-engineering, not a research, skill level — which cuts in favor of obviousness under KSR.


4. Prior-art inventory from the face of the patent (with reference dates)

Ref. Date(s) § 102 status Core disclosure
WO 01/58080 A1 — Beepcard Inc. (Atsmon et al.), Physical presence digital authentication system Prio. 2000-02-07; pub. 2001-08-09; sib. US 6,607,136 B1 (2003-08-19), US 7,706,838 § 102(b)/(a) Electronic card talks to a PC via the PC's own speaker and microphone using audible or ultrasonic sound; used to authenticate a user at a website and complete a sales transaction; "one-button" triggering of … logging in securely; base station reaches a web merchant/server; EDAC mechanisms — "bytes transmitted with parity, with on-the-fly error correction and detection," plus a CRC checksum byte; server-side authentication against an account DB; explicitly frames "card presence" as the answer to card-not-present fraud and repudiation.
WO 2005/011191 A1 — Qualcomm (Steenstra, Gantman, Rose et al.), Digital authentication over acoustic channel; US counterpart US 8,391,480 B2, US 7,487,362, US 7,533,735 Prio. 2002-02-15 / 2002-05-06 / 2003-07-22; pub. 2005-02-03 § 102(b)/(a) Token generates an access code using a cryptographic key and a time element; converter encodes the access code into sound waves (audio, ~1–3 kHz) output by a speaker; a wireless communication device (desktop, laptop, PDA, phone) receives the sound via its microphone and relays it over the Internet to a verifier device; verifier regenerates the code and "grants authentication if the access code corresponds to the second access code." Transmit path expressly includes a forward error correction (FEC) element ("FEC element 610 is configured to encode digital data bit sequence to be transmitted") and the receive path a corresponding decoder. Session-based: clocks "synchronized to generate a time element periodically, for example every minute, hour, day."
US 2014/0068272 A1 — Vasco Data Security (Marien, Savtchenko) Prov. 2011-02-25; US filing 2012-08-30; pub. 2014-03-06 § 102(a)(2)/(e) (via provisional) Strong-authentication token receiving data acoustically; explicitly a one-way acoustic input from a PC's speaker to a token microphone; FSK over multiple carrier frequencies; error detection codes — "a Cyclic Redundancy Code (CRC) … a check sum … a Luhn check digit … a Longitudinal Redundancy Check (LRC)"; extra redundancy blocks with XOR and modulo-addition reconstruction; token generates dynamic security values by cryptographically combining a secret with a time value, counter, challenge, or transaction data; keypad-less compact token.
US 9,098,691 B2 — Vasco (Hoornaert, Marien) (sibling of the above; NOT on the patent's face) Prov. 2011-02-25; fil. 2012-02-24 § 102(a)(2)/(e) Same acoustic-token disclosure with explicit error-detection/CRC and redundancy coding, and — critically — its face cites both WO 01/58080 and WO 2005/011191 (see § 7).
WO 2012/106380 A1 — Hill, Sonic based digital networking Prio. 2011-01-31; pub. 2012-08-09 § 102(a)/(b); also § 102(a)(2) via US national phase System = mobile device + merchant electronic device + central server. The central server includes a payment-processing module and a "token generator to generate a token." The mobile device has a network interface, user interface, acoustic transmitter, and a token receiver module that "receives the token from the central server through the network interface" and a translator module that "translates the token into … acoustic data," which the acoustic transmitter sends to the merchant-associated electronic device's acoustic receiver, whose decoder/processor handle it, with the central server coordinating and confirming the payment between the user's account and the merchant's account.
US 5,668,876 — Ericsson (Falk et al.), User authentication method and apparatus 1994-06-24 / 1997-09-16 § 102(b) Out-of-band (radio/mobile-telephony) delivery of time-/counter-limited authentication data to authenticate a remote user against a host; cited in Vasco's own background as the canonical "token receives data over an out-of-band channel" reference.
US 5,136,644 — Telecash, Portable electronic device for use in conjunction with a screen 1988 / 1992 § 102(b) Portable authentication device interacting with a display; cited by Vasco as optical-token art.
US 2003/0204726 A1 — Kefford, Methods and systems for secure transmission of information using a mobile device 2002-04-25 / 2003-10-30 § 102(b)/(a) Mobile device as the secure transactor for e-commerce.
US 2004/0153649 A1 — Rhoads, Digital authentication with digital and analog documents prio. 1995-07-27 / pub. 2004-08-05 § 102(b)/(a) Document/analog-channel authentication.
US 2007/0233615 A1; US 2007/0244811 A1; US 2007/0255662 A1 — Obopay Inc. 2006-03-30 / 2007 § 102(a) Mobile payment system; mobile client application for mobile payments; authenticating wireless person-to-person money transfers.
US 9,195,980 B2 — Nokia 2009-10-30 / 2015-11-24 § 102(e) Error/recovery handling during authentication.
US 7,801,826 B2 — Fujitsu 2002-08-08 / 2010-09-21 § 102(b)/(a) Framework for purchasing goods/services; cited family art.
US 2012/0297187 A1 — Google, Trusted mobile device based security fil./prio. 2011-05-17; pub. 2012-11-22 § 102(a)(2)/(e) Establishing a trusted mobile device as an authentication factor for web services.
US 8,478,990 B2 — Cryptite LLC 2011-06-02 / 2013-07-02 § 102(e) Mobile transaction tokens.
CN 104769622 A — Intel prio. 2011-12-21; pub. 2015-07-08 § 102(a)(2) via PCT "Method for authentication using biometric data for mobile device e-commerce transactions."
Obopay, Nokia, Fujitsu items as above — — Named for completeness; not load-bearing.
Visa US 9,516,487 / 9,680,942 / 10,484,345 / 10,664,844; Syniverse US 10,277,576; Seven Networks US 10,659,421 filed 2013–2017 (except Seven Networks 2004) Not prior art Excluded from this analysis.

5. Element-by-element mapping of Claim 1

Claim 1 limitation Beepcard WO 01/58080 (+ US 6,607,136) Qualcomm WO 2005/011191 (US 8,391,480) Hill WO 2012/106380 Vasco US 2014/0068272 / US 9,098,691
Client device with Internet/cloud path ("second path") PC + special client software + browser + web server WCD (desktop/laptop/PDA/phone) over Internet Mobile device "network interface" to central server PC/smartphone interacting with web app
Receiving device associated with e-commerce website PC with browser at web merchant Verifier device / secure-network server "electronic device … associated with a merchant's identification" PC / web application server
Option displayed, accepted to connect over near-field/short-range path ("first path") Website signals support; browser/tray alerts user; one-button trigger Actuator/switch on token initiates; Web-page flow User interface to display a program; token-receipt then acoustic emission Token button / web page flow
Authoritative server generates single-use token Server generates/authenticates codes; counter increments per activation (one-time series) Verifier generates matching access code "token generator to generate a token" at the central server OTP generated by cryptographically combining secret + dynamic value
Token encoded with an error control code "bytes transmitted with parity, with on-the-fly error correction and detection" + CRC checksum byte FEC element 610; decoder 770 (server-side token; coding a design choice) CRC / checksum / Luhn / LRC; XOR & modulo-addition redundancy
Token time limited < ~3 min Short-lived, counter-invalidated codes Time element; session-based, changes every minute/hour/day Token tied to a payment confirmation Time value / counter as dynamic variable
Client receives the token Card receives data via PC speaker Token generates locally; WCD relays Mobile device "receives the token from the central server through the network interface" Token receives acoustically
Transmit token via audible audio from speakers ("third path") Card⇄PC audible or ultrasonic; PC speakers used "audio waves having frequencies in the range of approximately 1 kHz to 3 kHz … a standard speaker" "acoustic transmitter" translating token to acoustic data Acoustic input to token
Receive token via microphone of receiving device ("fourth path")… PC microphone receives card signal Verifier "audio input unit 257" (microphone) Merchant "acoustic receiver" Token microphone (reverse direction)
Relayed to authoritative server ("fourth communication path") and compared there PC relays decoded data to authentication server which checks ID/group/counter WCD relays over Internet to verifier device; verifier "grants authentication if the access code corresponds to the second access code" Token/acoustic data used with central server to confirm payment Token→user→application server; server verifies the received dynamic security value
Verify identity to perform secure transaction Card-presence authentication of an e-commerce purchase Grants access to the secure network/application Confirms payment from user's to merchant's account Grants access / performs transaction
All four paths used before the transaction — — — — (mere order-of-steps recitation)

The only design details the asserted claims appear to add beyond this art are (i) which direction the audible channel runs (client-speaker → receiving-device-microphone, rather than PC-speaker → token-microphone as in Vasco, or card ↔ PC as in Beepcard), and (ii) a numeric <~3 minute bound on an admittedly short-lived token. Both are addressed in § 7.


6. Combination A (primary): Hill + Qualcomm + Beepcard

The combination. Take Hill's three-party architecture (central server with token generator → mobile device → acoustic transmission → merchant device → back to server to confirm payment); use Qualcomm's acoustic access-code/OTP mechanism, in which the acoustic signal carries a cryptographically generated, time-element-based code that a standard speaker and microphone handle, and the receiving computer relays it over the Internet to a verifier that compares and grants authentication on a match, with FEC applied to the transmitted bit stream; and adopt Beepcard's audible/ultrasonic, speaker-and-microphone, no-dedicated-reader physical-presence scheme for e-commerce card-present assurance, which already applies parity/on-the-fly error correction plus a CRC to the acoustic payload and authenticates server-side against a counter to defeat replay.

Every element of Claim 1 is present. That includes the two limitations most likely added during prosecution: error control coding (Beepcard's EDAC/parity/CRC; Qualcomm's FEC element 610) and a short, invalidated token life (Beepcard's incrementing counter/single-use series; Qualcomm's synchronized time element).

Why a POSITA would combine them (KSR rationales i–v):

  1. Same field, same problem, same solution space (rationale i). All three references are authentication-for-network-transactions references. Hill and Beepcard state the identical objective — letting a user authenticate/pay over the web without exposing or typing credentials, while proving the physical presence of an enrolled device. Qualcomm states it as securing remote access "over a public communication infrastructure such as the Internet" using an acoustic channel precisely to avoid "cumbersome" manual code entry. Combining them yields no change in the references' respective principles of operation.
  2. The elements are known and their functions unchanged (rationale i/ii). Token generation (Hill/Vasco/Qualcomm), acoustic transport (Hill/Beepcard/Qualcomm/Vasco), server-side comparison (Qualcomm/Beepcard/Vasco), and error coding (Beepcard/Qualcomm/Vasco) each do exactly what they did before.
  3. Simple substitution of a known acoustic carrier for another known carrier (rationale ii). Beepcard is emphatic that the whole point is to reuse "the conventional sound system in the base station so that a special reader hardware need not be installed." A POSITA seeking to move Hill's server→mobile→merchant token hop onto hardware that already exists would substitute the acoustic link of Beepcard/Qualcomm; the references expressly weigh the trade-off (Beepcard: audible gives greater range, ultrasonic gives less interference; Qualcomm: 1–3 kHz "such that a standard speaker … and a standard microphone" suffice).
  4. Applying a known technique to a known device ready for improvement (rationale iv). Qualcomm's own stated motivation — that displaying and manually keying OTPs is "cumbersome" — is exactly the deficiency Hill's acoustic token-transfer step removes. Likewise, Beepcard/Qualcomm's error coding is a known, off-the-shelf answer to the well-known problem that acoustic channels suffer multipath, echoes, and ambient noise; Beepcard and Vasco both say so in terms.
  5. "Obvious to try" over a finite, predictable set (rationale v). Given a need to move a short-lived token between a phone and a nearby browser-equipped device with no new hardware, the identified solutions were a small, enumerated set — acoustic, NFC/RF, optical/QR, magnetic — and the patent's own specification says so, listing "an audio signal, near field communications signal, Bluetooth-compatible signal, optical signal," and, for the code, "Hamming codes, Bose Chaudhuri-Hocquenghem codes, Reed Solomon codes, cyclic redundancy." Choosing a member of the recited set with a known benefit is obvious. That the patent's own independent claim recites both the acoustic-channel choice and the error-coding choice is itself evidence that these were conventional options, not inventions.

7. Combination B (independent, alternative): Beepcard + Vasco + Qualcomm

This combination is worth stating separately because it is robust to the priority question and because the references are welded together by their own citation practice.

Beepcard supplies: audible speaker→microphone physical-presence authentication for web login and purchase; parity/on-the-fly error correction and CRC on an acoustically transmitted payload; server-side comparison; a counter that invalidates each transmission for replay (i.e., single-use); and the express rationale that card presence defeats card-not-present fraud — which is the very security problem Claim 1's preamble addresses.

Qualcomm supplies: the token generates a cryptographic, time-based access code; the code is encoded into sound waves at audible frequencies (1–3 kHz); a standard speaker emits and a standard microphone receives; the receiving computer relays over the Internet to a verifier; the verifier compares and grants authentication on correspondence; and forward error correction is applied to the bit sequence.

Vasco (US 2014/0068272 and/or US 9,098,691) supplies, with dates running to a 2011-02-25 provisional: acoustic data input to an authentication token over a one-way acoustic channel; explicit error-control coding (CRC, checksum, Luhn, LRC); XOR and modulo-addition redundancy/reconstruction; and the canonical framing of the whole problem — dynamic security values (OTPs) generated by combining a shared secret with a time value, counter, challenge, or transaction data, because the token is the "trustworthy" factor relative to a PC.

Motivation — evidenced inside the references themselves. This is the strongest possible KSR showing, because it is not inferred: the face of US 9,098,691 lists both WO 01/58080 (Beepcard) and WO 2005/011191 (Qualcomm) as cited references (https://patentimages.storage.googleapis.com/7c/c2/92/a252a1d422bd68/US9098691.pdf). A reference that cites both members of the proposed combination — and whose entire disclosure is about acoustically receiving data at an authentication token for remote transactions over a network — establishes that these references were known to artisans working in this exact niche and were considered pertinent to one another. Vasco's corresponding US 2014/0068272 specification additionally cites Ericsson's US 5,668,876 for the proposition that authentication tokens may receive data over an out-of-band channel, confirming the field's familiarity with the token-delivery problem the patent claims to solve.

On the two "extra" limitations:

  • Direction of the audible channel. Vasco runs its acoustic link PC-speaker → token-microphone; Claim 1 runs client-speaker → receiving-device-microphone. Running a bidirectional-capable acoustic link in the other direction is a predictable reversal of parts with no new function (KSR, rationale ii), and Beepcard/Qualcomm already disclose the client-device-as-transmitter and the computing-device-as-receiver directions (Beepcard's card→PC mode; Qualcomm's token→WCD flow). There is no teaching away.
  • "Time limited to less than approximately three minutes." Qualcomm's code changes on a synchronized periodic time element ("every minute, hour, day"); Beepcard's series advances on every press and the account record tracks the last-used counter, which invalidates any replay; Vasco's OTP is a function of a time value/counter. Once the token is single-use and server-compared, the <~3-minute bound is a result-effective variable with no criticality alleged, supported only by the patent's own "fraction of a second … a few seconds … a few minutes" discussion. Nothing in the specification establishes an unexpected result at three minutes. Under KSR, where the only difference is a recitation of an obviously desirable limit on a known parameter, the claim is obvious.

8. Claim 7 (system claim)

Claim 7 recites the same four communication paths and the same server components (token generator; token "time limited to less than approximately three minutes"; interface to convey an error-control-coded token; processor to trigger audible transmission from the client's speakers to the receiving device's microphone, obtain the token back, and authenticate by comparison).

Each recited structure is disclosed by the art mapped in § 5:

  • Client device with NFC interface + wireless interface + audible transmission interface → Hill's mobile device (network interface + user interface + acoustic transmitter); Qualcomm's token/WCD pair; Beepcard's card (RF/acoustic/ultrasonic/magnetic variants are expressly disclosed in Beepcard § 6 "Non-Acoustic Embodiments" — which forecloses any argument that NFC + acoustic coexistence is inventive).
  • Receiving device with NFC interface + wireless interface + Internet interface + audible reception interface → Hill's electronic device with acoustic receiver associated with the merchant; Beepcard's PC with microphone, speakers, and browser; Qualcomm's WCD with audio input unit and Internet connection.
  • Authoritative server in wireless communication with both → Hill's central server with token generator and payment-processing module; Qualcomm's verifier device; Beepcard's authentication server.
  • Processor that triggers audible transmission, obtains the token back from the receiving device, and authenticates by comparison → Qualcomm ("grants authentication if the access code corresponds to the second access code"); Beepcard (server "checks the individual ID … decrypts … checks the counter value"); Hill (server confirms payment).

Therefore Claim 7 stands or falls with Claim 1. The same combinations and the same motivations apply.


9. Dependent claims 2–6 and 8–11

Claim Limitation What renders it obvious
2 Conducting the secure transaction over the Internet Beepcard (web purchase; merchant/server over the Internet); Hill (network/payment); Qualcomm (secure network over the Internet).
3 Server authenticates the client upon acceptance of the option Beepcard § 5.3.2 "On-Line Authentication" (card activation → authentication server); Qualcomm's verifier grant; Obopay's mobile-payment authentication.
4 Biometric authentication — retinal scan, palm print, voice print, keyword annunciation, thumbprint CN 104769622 A (Intel, prio. 2011-12-21) is literally titled "Method for authentication using biometric data for mobile device e-commerce transactions." Beepcard also ties its acoustic system to voice technologies ("Additional Synergies with Voice"), expressly invoking the "something you are" biometric factor alongside "something you have." Selecting among retinal scan / palm print / voice print / thumbprint is a finite, enumerated list of known biometrics (KSR, rationale v), and the patent's own specification concedes "Most modern personal communications devices all include a camera and microphone" — i.e., no new hardware.
5 Receiving device = laptop/desktop/smartphone running a browser Qualcomm: WCD "may be various other computing devices such as but is not limited to laptop computer, PDAs, wireless phones"; Beepcard: PC with web browser; Hill: merchant electronic device + mobile device.
6 Client device = laptop/desktop/smartphone running a browser Same references; Beepcard's special client software runs in the PC browser context (ActiveX/Java applet); Qualcomm's token may be "embedded into another device such as a wireless phone or a personal data assistant."
8 Approve transaction on a match Qualcomm claim 30 ("grant access if the access code is verified"); Hill (server confirms the payment); Beepcard (site authorizes redemption).
9 Deny transaction on a mismatch Qualcomm (access denied if not verified); Beepcard ("If the password is not valid, the website will deny the redemption request"); Beepcard's challenge-response flow sounds a "buzzer" on failure.
10 Perform a mathematical operation to establish a match Beepcard's Series comparison and counter check; Vasco's XOR / modulo-addition redundancy and reconstruction ("calculating at least part of the missing input data … comprises performing a bitwise exclusive-or operation," "a modulo addition"); Beepcard's pattern-recognition comparator.
11 The operation is addition, subtraction, convolution, comparison, correlation, or any combination Each named operation is a textbook primitive; Beepcard's pattern-recognition engine performs correlation/feature comparison over audio; Vasco performs XOR (addition mod 2) and modulo addition. Enumerating these alternatives is the paradigm of an obvious list of known options — and the patent's own specification says the tokens "may be added … subtracted … multiplied … convolved, or undergo any other logical or mathematical operation," which concedes the breadth.

10. Secondary considerations (§ 103 rebuttal analysis)

I found no evidence in the record of objective indicia, and several indications cut the other way:

  • No commercial-success or industry-praise evidence appears in the file; the patent's own prior-art discussion (passwords, password reuse, notebook/electronic files) shows the problem was old and widely recognized, which supports obviousness rather than non-obviousness.
  • No nexus is apparent between any alleged success and the two narrow limitations (error-control code; <~3 min). The alleged benefit — "the presence of only actual, human users," replacing CAPTCHA — is attributed by the specification to the use of "a personal communications device, which may inherently require intelligent manipulation by the user," a benefit Beepcard already delivers via its one-button physical-presence card. Beepcard's own patent is even captioned "Physical presence digital authentication system." There is therefore no unexpected result traceable to the asserted points of novelty.
  • No teaching away. Beepcard teaches both audible and ultrasonic operation (so the "audible audio signal" limitation is a disclosed option, not a discovery); Vasco teaches that the acoustic link is cost-effective and requires no special hardware (motivating, not discouraging); Qualcomm teaches that error correction improves acoustic transmission (motivating the error-control-code limitation).
  • Potential double-patenting / claim-differentiation concern between Claims 1 and 7 is a § 112/§ 101 issue, not a § 103 saving grace.

11. Bottom line

Claim 1 is obvious under § 103 over at least two independent three-reference combinations:

  • Hill (WO 2012/106380 A1) in view of Qualcomm (WO 2005/011191 A1 / US 8,391,480 B2), further in view of Beepcard (WO 01/58080 A1 / US 6,607,136 B1); and
  • Beepcard in view of Vasco (US 2014/0068272 A1 and/or US 9,098,691 B2), further in view of Qualcomm.

Claim 7 is obvious on the same combinations, plus US 5,136,644, US 5,668,876, and US 2003/0204726 A1 as secondary evidence of the state of the art for the structural interfaces. Claims 2–6 and 8–11 are obvious over the same primary combinations, with CN 104769622 A (biometrics), Obopay (mobile payment), and US 5,668,876 (time-limited out-of-band authentication) supplying the dependent-claim features. The KSR motivation is unusually well evidenced here because the references cross-cite one another — most strikingly, Vasco's US 9,098,691 B2 lists both Beepcard's WO 01/58080 and Qualcomm's WO 2005/011191 on its face.

Candor about limits of this opinion:

  1. I have not reviewed the prosecution history. If the "error control code" and "<~3 minute" limitations were added late, (a) that corroborates a prior-art-driven narrowing, and (b) it may shift the effective filing date off 2012-08-13, which strengthens Combination B.
  2. I relied on the Google Patents citation table and each reference's own published text; I did not verify every cited reference's § 102 date by pulling its full priority chain from USPTO records, and I did not independently confirm the contents of Obopay's three applications or US 2012/0297187 beyond the citation data here — treat those as supporting, not load-bearing.
  3. My confidence is high on the Combination A and Combination B mappings (the reference texts are quoted above), moderate-high on the dependent-claim mappings, and moderate on the priority-date premise, which is the single biggest swing factor in the whole analysis.
  4. If a formal validity opinion is required, the next steps are: (i) pull the 13/964,593 and 14/293,112 file wrappers from PatentCenter to confirm the amendment dates for the two narrow limitations; (ii) confirm the reference dates via the USPTO priority chains for Vasco 61/446,779 and Hill's PCT; and (iii) run a full prior-art search beyond the cited art.

Sources: https://patents.google.com/patent/US11317279/en · https://patents.google.com/patent/WO2001058080A1 · https://uspto.report/patent/grant/7706838 · https://patents.google.com/patent/WO2005011191A1/en · https://patents.google.com/patent/US8391480 · https://patents.google.com/patent/US20140068272 · https://patentimages.storage.googleapis.com/48/0b/8e/9f43fca3a154d2/US20140068272A1.pdf · https://patentimages.storage.googleapis.com/7c/c2/92/a252a1d422bd68/US9098691.pdf · https://patents.google.com/patent/WO2012106380A1/en · https://patentimages.storage.googleapis.com/66/87/b0/3d853f69e88bea/EP2530552A1.pdf

Generated 9/29/2026, 10:53:51 AM

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

Other patents in Financial Technology (FT)

See all Financial Technology (FT) patents →