US 10491646

Summary of U.S. Patent No. 10,491,646 (US10491646B2)

I searched for the specific patent number 10491646 (front-page form: US 10,491,646 B2) and did not rely on similar numbers (e.g., 8,166,892, IPR2025-01046/01047, etc., which appeared in unrelated search results). The authoritative bibliographic data below is confirmed by the USPTO patent PDF (patentimages.storage.googleapis.com/b2/1b/f3/ecafc7c6e84368/US10491646.pdf), Google Patents, and Justia.

Bibliographic data

• Title: Mechanism for Facilitating User-Controlled Features Relating to Media Content in Multiple Online Media Communities and Networks
• Patent number: US 10,491,646 B2
• Inventor: Bradly Freeman Rich, Paradise Valley, AZ (US)
• Original applicant/assignee (as printed on the patent): Sonafire, Inc., Denver, CO (US)
• Current assignee (per Google Patents assignment record dated 2025-10-15): Dynamuse LLC (assigned by Sonafire, Inc.)
• Application: No. 14/933,983, filed November 5, 2015 (continuation of U.S. Application No. 13/779,113, filed Feb. 27, 2013, which issued as U.S. Patent No. 9,225,580 on Dec. 29, 2015; claiming priority to U.S. Provisional Application No. 61/605,090, filed Feb. 29, 2012)
• Issue date: November 26, 2019
• Prior publication: US 2016/0127436 A1 (May 5, 2016)
• Examiner / attorney of record: Ninos Donabed; Jaffery Watson Mendonsa & Hamilton LLP
• Scope: 18 claims, 24 drawing sheets; CPC classes include H04L 65/60, G06F 16/40, G06Q 50/01, H04L 67/06, H04N 21/26258, H04N 21/4722, H04N 21/4788
• Status per Google Patents: Active; anticipated expiration 2033-02-27 (with disclaimer note: some third-party pages show maintenance-fee "lapse" language, but that appears tied to the parent patent 9,225,580 or another matter on the same page, not to the '646 patent, which Google Patents lists as Active and which is being asserted in 2025–2026 litigation)

Abstract (verbatim)

"In accordance with embodiments, there are provided mechanisms and methods for facilitating playlist assistance and sharing of media content over multiple media communities according to one embodiment. In one embodiment and by way of example, a method includes receiving, at a first computing device, a request relating to media content. The request may be placed by a user at a second computing device. The method may further include researching a plurality of media playlists at a plurality of media communities for the media content, selecting one or more of the plurality of media playlists at one or more of the media communities having the media content, and transmitting, from the first computing to the second computing device, the one or more media playlists having the media content."

Plain-language overview of the invention

The patent describes "playlist assistance" software: when a user is listening to or selects a media item (e.g., a song) in a media player, the system searches across the user's playlists spread over multiple online media communities/social networks (e.g., Spotify, YouTube, Facebook, SoundCloud) and returns the playlists that contain that song, artist, or genre — eliminating the need to manually open each playlist. It also covers related features: sorting results by user preference, modifying (deleting/moving/shuffling) playlist content, sharing media with other users, and audio-recognition-based sharing of files playing through external speakers.

Independent claims — overview and uncertainty

I was not able to retrieve the verified, full text of every independent claim from the available sources (the Google Patents claim text was not included in the provided material, and the fetched front-page PDF confirms only "18 Claims" without reproducing them). Based on the specification's embodiment summaries, the claim set appears to follow the standard three-claim format typical of this family:

• An independent method claim — receiving, at a first computing device, a request relating to media content placed by a user at a second computing device; researching a plurality of media playlists at a plurality of media communities for the media content; selecting playlists having the media content; and transmitting those playlists to the second computing device. Dependent method claims add evaluating the request, sorting by user preference, sharing media via email/text/posting, displaying/playing results, and network types (LAN, WAN, MAN, PAN, intranet, extranet, Internet, cloud).
• An independent system claim — a computing device with memory and a processing device executing a mechanism to perform the same receive/research/select/transmit functions (with corresponding dependent system limitations).
• An independent machine-readable-medium claim (per the specification's "at least one machine-readable storage medium ... causes the computing device to carry out a method" language).

Caveat: One litigation-complaint analysis (for Dynamuse LLC v. iHeartMedia Inc., W.D. Tex. 7:26-cv-00116, filed 2026-03-31) describes asserted claim 1 as including UI-focused limitations — displaying an interactive user interface while playing a media item, facilitating selection of a "playlist assistance function," and returning "exactly matched" results as a "final output without any recommendations or suggestions." That source is third-party and possibly unreliable, and I could not independently verify that exact claim language against the USPTO record. Treat claim-level details as unverified unless confirmed against the issued claim text.

Litigation / CAFC 2026 dockets

• No CAFC (Federal Circuit) 2026 docket for patent 10491646 was found in my searches — I could not confirm any appeal at the Federal Circuit involving this patent. My CAFC-specific search returned no results.
• District court litigation confirmed/identified (per Google Patents litigation links and case-analysis pages):
  • E.D. Tex.: 2:25-cv-01110, 2:25-cv-01111 (Dynamuse LLC v. Idagio GmbH, filed 2025-11-06), 2:25-cv-01112, 2:25-cv-01113, 2:25-cv-01114
  • W.D. Tex.: 7:26-cv-00116 (Dynamuse LLC v. iHeartMedia Inc., filed 2026-03-31)
  • N.D. Tex.: 3:26-cv-00803
• Plaintiff in these cases is Dynamuse LLC (New Mexico), consistent with the 2025 assignment; counsel per one filing: Rabicoff Law LLC.

Sources

• USPTO patent PDF: https://patentimages.storage.googleapis.com/b2/1b/f3/ecafc7c6e84368/US10491646.pdf
• Google Patents: https://patents.google.com/patent/US10491646/en
• Justia: https://patents.justia.com/patent/10491646
• W.D. Tex. complaint analysis (7:26-cv-00116): https://ai-lab.exparte.com/case/dct/txwd/7:26-cv-00116/doc/analysis/1
• E.D. Tex. complaint analysis (2:25-cv-01111): https://ai-lab-cl-prod.azurewebsites.net/case/dct/txed/2:25-cv-01111/doc/analysis/1

Bottom line: US10491646 is a granted, active patent titled "Mechanism for Facilitating User-Controlled Features Relating to Media Content in Multiple Online Media Communities and Networks," invented by Bradly Freeman Rich, originally assigned to Sonafire Inc. and now to Dynamuse LLC, filed Nov. 5, 2015, and issued Nov. 26, 2019. It claims playlist-assistance search/selection/transmission across multiple online media communities. No Federal Circuit 2026 appeal was located; the patent is currently being asserted in multiple Texas district court cases. The exact independent-claim text (particularly claim 1's UI/"exactly matched" limitations) could not be fully verified from the sources retrieved, so that portion is reported with that uncertainty flagged.

Litigation Involving U.S. Patent No. 10,491,646 (printed as US10491646)

Based on searches of the Stanford NPE Litigation Database, PACER/PacerMonitor, CourtListener, the Unified Patents litigation data referenced on the patent's Google Patents page, and Ex Parte complaint analyses, US 10491646 is actively asserted in a 2025–2026 litigation campaign by DynaMuse LLC (a New Mexico NPE; the patent was assigned from Sonafire, Inc. to DynaMuse LLC effective 2025-10-15). All cases identified are patent-infringement suits filed by DynaMuse LLC (counsel: Rabicoff Law LLC / Isaac P. Rabicoff) against online music/media services. Note that each docket entry below reflects cases flagged as involving the '646 patent; I confirmed the '646 patent is specifically at issue in at least the IDAGIO, iHeartMedia, Mixcloud, and Xandrie matters via the sources cited.

Cases filed in the Eastern District of Texas (all assigned to Judge Rodney Gilstrap; filed together in a wave on/about November 6, 2025)

Cases filed in other Texas districts (2026 wave)

Key observations and caveats

• Venue pattern: The E.D. Tex. wave (cases 2:25-cv-01110 through 2:25-cv-01114, filed ~Nov 6, 2025) was consolidated for pretrial purposes under lead case 2:25-cv-01113 (SoundCloud) by order of Judge Gilstrap dated Dec 15, 2025, with a scheduling/case-management conference set for Jan 22, 2026.
• SoundCloud status: DynaMuse filed a Notice of Voluntary Dismissal in the lead SoundCloud case on Jan 8, 2026 — likely signaling dismissal of that defendant (commonly a settlement or strategic dismissal); the effect on the consolidated companion cases is not clear from the retrieved snippets.
• Confirmations: The Stanford NPE Litigation Database specifically lists US 10491646 as asserted in DynaMuse LLC v. Mixcloud Ltd. (2:25-cv-01112) and DynaMuse LLC v. Xandrie S.A. (2:25-cv-01114). Ex Parte complaint analyses specifically identify the '646 patent as the patent-in-suit in DynaMuse v. IDAGIO (2:25-cv-01111) and DynaMuse v. iHeartMedia (7:26-cv-00116). The Google Patents page for US10491646 lists all seven case numbers above (2:25-cv-01110, 01111, 01112, 01113, 01114, 7:26-cv-00116, and 3:26-cv-00803) as litigation associated with this patent.
• No judgments: None of the retrieved records shows a final judgment, merits ruling, finding of infringement, or invalidity decision. No IPRs were identified in the retrieved sources.
• Not fully verified: Exact filing dates for 2:25-cv-01110, 01112, and 01114 are inferred from ECF/PACER timestamps showing complaint and summons activity on Nov 6, 2025, and from the case-number sequencing; the exact filing date for the N.D. Tex. Sirius XM case (3:26-cv-00803) was not confirmed in the snippets retrieved. Individual complaints may assert additional patents beyond the '646 patent (the retrieved complaint analyses for IDAGIO and iHeartMedia reference the '646 patent specifically, with infringement allegations tied to that patent).

Bottom line: Yes — US 10491646 is the subject of at least seven known infringement cases filed by DynaMuse LLC in late 2025 and early 2026 against Deezer, IDAGIO, Mixcloud, SoundCloud, Xandrie (Deezer-related), iHeartMedia, and Sirius XM. The SoundCloud case was voluntarily dismissed in January 2026; the remainder were open as of the most recent retrieved docket data.

Proceedings overview

There are zero AIA trial proceedings (IPR/PGR/CBM) on file for US 10491646 — the USPTO ODP structured data reports none, and web searches (including PTAB-specific and Unified Patents litigation-portal queries) surfaced no petition, institution decision, or Final Written Decision against this patent. For a defendant, that means the patent is completely PTAB-untested: every claim (1 through the full independent/dependent set) remains prima facie valid, no estoppel under § 315(e)(2) binds anyone, and the only prior-art kill shots available are the ones defendants themselves bring.

No PTAB proceedings on file

• Type: N/A — no Inter Partes Review, Post-Grant Review, or Covered Business Method petition identified
• Filed: N/A
• Status: No AIA trial activity per USPTO Open Data Portal (most recent ingest) and per independent web search as of 2026-09-08
• Judge panel: N/A
• Petition grounds: N/A
• Institution decision: N/A
• Final Written Decision: N/A
• Settlement / termination: N/A
• Appeal: N/A
• Defensive value: The absence of PTAB activity is not a merits ruling — it is an open door. No prior-art ground has been tested or exhausted against this patent, and no petitioner or privy holds § 315(e)(2) estoppel that could block a later challenger. Caveat: I searched PTAB decision databases and general web sources; a petition filed within the last several weeks could exist that neither the ODP ingest nor my searches have yet indexed. If you have a case number or filing date, I can verify it against PTAB E2E directly.

Strategic summary

Claim-level status: all claims UNTESTED. US 10491646 issued 2019-11-26 from application 14/933,983 (a continuation of 13/779,113, itself claiming priority to provisional 61/605,090 filed 2012-02-29). Because no IPR/PGR/CBM has ever been instituted, none of its claims — the independent method claim directed to receiving a media-content request, researching media playlists across media communities, selecting playlists having the content, and transmitting them to the requesting device, plus the system/apparatus claims — have been canceled or even substantively reviewed by the Board. The patent is presently assigned to DynaMuse LLC (assignment recorded 2025-10-15 from Sonafire Inc.) and is active, with anticipated expiration 2033-02-27 (including patent term adjustment). Any assertion against a defendant today rests on claims that have never survived (or failed) a PTAB challenge, so prior-art viability is entirely undetermined.

Estoppel landscape — wide open. With no IPR history, § 315(e)(2) estoppel is a non-issue: no petitioner has raised, or been deemed to have "reasonably could have raised," any ground. That said, the practical constraint for a defendant currently being sued is § 315(b)'s one-year bar: an IPR petition must be filed within one year of service of a complaint alleging infringement. The patent's Google Patents record shows 2025 E.D. Tex. cases (e.g., 2:25-cv-01110 through 2:25-cv-01114, including DynaMuse LLC v. Mixcloud Ltd. and DynaMuse LLC v. Xandrie S.A. per Stanford NPE litigation data) and 2026 cases in the W.D. Tex. (7:26-cv-00116) and N.D. Tex. (3:26-cv-00803). Any defendant served more than one year ago on a complaint asserting this patent has already lost the IPR window unless it can invoke an exception (e.g., a later-served, separately actionable complaint or a different patent in the family). Defendants served within the past year — or not yet sued — retain the full universe of § 102/§ 103 grounds, with no PTAB estoppel from anyone else.

Pattern signals. There is no serial-petitioner pattern, no patent-owner PTAB appellate history, and no defensive-aggregator IPR campaign — because there have been no proceedings at all. The one notable pattern is on the litigation side: the patent is now in the hands of DynaMuse LLC, a monetization entity, which filed a cluster of E.D. Tex. cases in 2025 (per Unified Patents litigation data referenced on the Google Patents record) and additional Texas cases in 2026. That is the classic profile of a patent that will attract IPR petitions — NPEs asserting a broad, software-method claim across multiple defendants usually generate at least one well-funded challenge. The current silence is more likely a function of petition timing (the first E.D. Tex. complaints were filed 2025, and the one-year § 315(b) clock for many defendants may still be running) than of the claims being uniquely robust.

Recommended next steps

1. Confirm the absence before relying on it. Check PTAB E2E (https://ptab.uspto.gov) directly by patent number and by litigant name ("DynaMuse," "Sonafire") — and also check the family members (US 2020/0236153 A1, filed 2019-11-22, and US 2024/0171624 A1, filed 2023-07-18, continuations of the same line). An IPR can only be brought on an issued patent, and the continuations may have issued by now or be asserted in parallel — a petition against a family member would not appear under this patent number.

2. If you are a defendant and within the § 315(b) one-year window — move now. Run a prior-art search targeting the claim's core limitations: "receiving a request relating to media content," "researching a plurality of media playlists at a plurality of media communities," and "transmitting the one or more media playlists." Pre-2012 playlist-aggregation and music-sharing systems (and the provisional's Feb. 2012 priority date caps the art window) are the promising hunting ground. Because nothing has been tested, the reasonable-likelihood-of-success bar is assessed fresh — no FWD exists to handicap you.

3. If you were served more than a year ago, evaluate the carve-outs. Check whether you were served on a complaint asserting this patent number specifically, whether service occurred within the last year for any co-defendant situation you can piggyback on (petitions may be joined or timed off the earliest complaint against a real party in interest), and whether § 315(b) analysis under Click-to-Call / Facebook creates any argument that the relevant "complaint" post-dates your receipt. If the IPR door is closed, your remaining validity lever is § 282/§ 112 and § 102/§ 103 in district court, where the burden is clear-and-convincing rather than preponderance.

4. Monitor the district-court dockets. The 2025–2026 DynaMuse cases (E.D. Tex. 2:25-cv-01110–01114; W.D. Tex. 7:26-cv-00116; N.D. Tex. 3:26-cv-00803) will reveal the asserted claims, proposed constructions, and whether DynaMuse is pursuing early settlements — all of which inform whether a coordinated, multi-defendant IPR (with cost sharing and prior-art development) is worth forming.

Bottom line: There is no PTAB history to cite — no FWD, no canceled claims, no settlement, no CAFC appeal. The patent is fully intact and fully challengeable. For a defendant, this cuts both ways: you cannot point to any Board decision as a defensive shield, but you also face no estoppel and no "hardened patent" narrative — a well-constructed IPR petition remains the highest-leverage validity attack available, provided you file inside the one-year bar. If your demand letter or complaint arrived within the last 12 months, treat an IPR filing deadline as your single most important date.

The searches aren't surfacing USPTO reel/frame data directly. Let me try targeted queries against the assignment records and related entities.

I was unable to pull the USPTO Assignment Center's reel/frame and correspondent data for this patent through the available search tools (the Assignment Center database is interactive and its record pages are not indexed by the search engines I queried). I have therefore reconstructed the chain from the next-best authoritative sources — the Google Patents legal-events feed for US10491646 (which derives from USPTO assignment records), the issued patent itself, and the Stanford NPE Litigation Database — and I flag every item that could not be verified against the primary reel/frame record rather than inventing it.

Inventors

• Bradly Freeman Rich (Paradise Valley, AZ, US) — sole named inventor.
• Employer at the time of filing: Sonafire, Inc. (Denver, CO), which is the applicant and original assignee of record on the parent application (13/779,113) and on the issued '646 patent. Rich is the named inventor on the provisional (61/605,090, filed 2012-02-29) and appears to have been principal of Sonafire (the specification repeatedly references "Sonafire®" as the service provider / home website).
• Unusual patterns: none in the inventor sense — there is a single inventor and no mass-departure pattern of the kind that precedes portfolio fire-sales. The notable pattern is on the entity side: Sonafire held the family for roughly a decade (2012 provisional through the 2023 continuation) and then transferred the entire family to an LLC in October 2025, roughly three weeks before the first infringement suits.

Original assignee

• Sonafire, Inc., Denver, CO (US) — the assignee named on the issued patent and on Google Patents as "Original Assignee."
• Line of business: consumer online music/social-media community (the "Sonafire" service described throughout the specification — soundboard, playlist assist, song sharing). The specification and screenshots (FIGS. 4A–4M) describe a shipped-looking web/mobile product, but I found no independent evidence of commercial deployment or revenue; treat "shipped a product embodying the claims" as unclear.
• Current status: not operating as a public or visibly active concern as of 2025–2026; it transferred its patent assets out on 2025-10-15. I found no bankruptcy filings, so status is best characterized as dormant/dissolved-in-fact — unclear, not bankruptcy.

Assignment timeline

USPTO Assignment Center records exist for this patent (the Google Patents legal-event feed shows a recorded reassignment), but I could not verify the reel/frame numbers or the correspondent of record from any indexed source. The entries below are therefore given with the dates and parties confirmed from the Google Patents legal-events feed and the issued patent; reel/frame and correspondent fields are marked unverified and should be confirmed at the USPTO Assignment Center search page (https://assignmentcenter.uspto.gov/ — search Patent No. 10491646; or https://assignment.uspto.gov/patent/index.html#/patent/search).

1. Pre-issuance, date unverified / recorded before or at grant (2015–2019 window) — Reel unverified

   • Conveyance: Assignment (inventor → company; reflected in the patent naming Sonafire, Inc. as original assignee at grant on 2019-11-26)
   • Assignor: Bradly Freeman Rich
   • Assignee: Sonafire, Inc.
   • Correspondent: unverified
   • Context: Original assignment of the invention to the startup applicant — normal and expected; this is why the '646 patent issued to Sonafire.

2. 2025-10-15 (executed and recorded per Google Patents legal events) — Reel unverified

   • Conveyance: Assignment of Assignor's Interest (per Google Patents: "ASSIGNMENT OF ASSIGNOR'S INTEREST")
   • Assignor: Sonafire, Inc.
   • Assignee: Dynamuse LLC (per Google Patents "Current Assignee"; litigation documents style the plaintiff "DynaMuse LLC")
   • Correspondent: unverified
   • Context: Transfer-to-asserter — the entire Sonafire patent family (including the '646 patent and its continuations) moved to an LLC that filed its first infringement suits within ~3 weeks.

No other post-issuance assignments (no security agreements, mergers, licenses, or releases) surfaced in the indexed sources. Note: because the USPTO record itself could not be opened, the possibility of additional recorded instruments (e.g., earlier security agreements or the exact reel/frame of the Rich→Sonafire assignment) cannot be excluded.

Timeline diagram

timeline
    title Ownership of US 10491646
    2012 : Provisional filed by Rich
    2013 : Utility application filed by Sonafire Inc
    2015 : Parent patent 9225580 issued
    2019 : US10491646 issued to Sonafire Inc
    2025 : Assigned to Dynamuse LLC
         : First infringement suits filed
    2026 : Second wave of suits filed

NPE / troll-pattern signals

1. Shell-entity transfer — present (weak-to-moderate). The patent moved on 2025-10-15 from Sonafire, Inc. (the developer of the described product) to Dynamuse LLC, which per the litigation record has no products and appears only as a plaintiff. Supporting evidence is the Google Patents reassignment event plus seven infringement complaints filed in Dynamuse's name; I could not verify a registered-agent address or single-member status, so this rests on transfer-to-LLC-plus-no-product rather than on address tells.

2. Known asserter in the chain — present (strong). The Stanford NPE Litigation Database lists DynaMuse LLC as the "Patent Asserter" against Mixcloud (2:25-cv-01112) and Xandrie (2:25-cv-01114), categorizing the campaign as "Acquired patents"; Unified Patents litigation data (linked from the patent's Google Patents page) likewise tracks DynaMuse's E.D. Tex., W.D. Tex., and N.D. Tex. cases as NPE assertion activity. Dynamuse is not on the legacy Acacia/Marathon/IPV list, but it is a high-frequency single-patent-family plaintiff as surfaced by Stanford and Unified Patents.

3. Repeat correspondent across the chain — unclear / not verified. I could not retrieve the correspondent-of-record for any assignment in this chain. No finding is possible without the USPTO record; this is the single most important field to check on the reel once the Assignment Center is opened.

4. Cascading transfers — not present based on available data. Only one post-issuance transfer (Sonafire → Dynamuse, 2025-10-15) was identified; there is no chain of chained LLCs within 24 months.

5. Pre-litigation transfer — present (strong). The assignment to Dynamuse LLC is dated 2025-10-15; the first E.D. Tex. complaints naming the '646 patent (2:25-cv-01110 through 2:25-cv-01114) were filed 2025-11-06 — roughly three weeks later, squarely inside the six-month window and consistent with a transfer arranged to establish a clean standing/venue record for assertion.

6. Bankruptcy fire-sale — not present. No Chapter 7/11 proceedings for Sonafire, Inc. were found in any indexed source.

7. Privateering — unclear / not present. There is no evidence Sonafire (an operating company) is directing Dynamuse's suits against its competitors; Sonafire itself appears dormant, which points to an acquired-patent assertion model rather than classic privateering. No SEC filings surface because neither entity is public.

8. Defensive aggregator (anti-NPE) — not present. The chain terminates at the asserting plaintiff (Dynamuse LLC), not at RPX, AST, LOT, Unified Patents, or OIN. Inverse signal: the patent is not neutralized.

Verdict

NPE — high confidence

Two strong, independently corroborated signals drive this: (1) the current assignee, Dynamuse LLC, is a non-product LLC that acquired the patent on 2025-10-15 and is tracked as a patent asserter by the Stanford NPE Litigation Database and Unified Patents litigation data (cases 2:25-cv-01110–01114, 7:26-cv-00116, 3:26-cv-00803); and (2) the assignment landed approximately three weeks before the first wave of infringement suits (filed 2025-11-06), the classic transfer-to-asserter timing pattern. The one gap in the record — the USPTO reel/frame numbers and correspondent names, which I could not retrieve and therefore did not fabricate — should be confirmed at https://assignmentcenter.uspto.gov/ (search Patent No. 10491646); if the correspondent handling the Sonafire→Dynamuse recording is a repeat player across other Dynamuse-family patents, that would further corroborate the verdict, but the available evidence already supports high confidence.

I have to stop making tool calls (session limit reached), so here is my analysis based on the verified materials I did retrieve — most importantly a snippet of the USPTO patent PDF for US 10,491,646 B2 (patentimages.storage.googleapis.com/b2/1b/f3/ecafc7c6e84368/US10491646.pdf) showing the "(56) References Cited" section. That snippet is partial — it breaks off mid-list after US 2004/0019497 A1 with a "(Continued)" marker — so I cannot confirm the complete set (additional U.S. documents, any foreign patent documents, or "Other Publications"/NPL). I flag each item's verification status below rather than fabricating what I could not retrieve.

1. Methodology and verification status

• Source of citation list: USPTO-issued PDF of the '646 patent (verified). The snippet reproduced, in order: 6,389,467 B1 (Eval, 5/2002); 6,434,621 B1 (Pezzillo, 8/2002); 7,254,618 B1 (Swenson, 8/2007); then "(Continued)"; 7,985,911 B2 (Oppenheimer, 7/2011); 8,175,989 B1 (Gopinath, 5/2012); 8,258,390 B1 (Gossweller, 9/2012); 8,688,991 B1 (Sunil, 4/2014); 2003/0037036 A1 (Weare, 2/2003); 2003/0221541 A1 (Platt, 12/2003); 2004/0019497 A1 (Volk, 1/2004).
• Not retrieved: the remainder of the U.S. list after Volk, any foreign patent documents, and any NPL. The Google Patents "Patent Citations" table for the '646 was not present in the fetched full-text page and could not be independently re-fetched this session.
• Claim text caveat (carried forward from the earlier sections): the issued claim language (especially claim 1) was not independently verified from the USPTO record in this session. The § 102 mapping below therefore uses the claim elements as summarized from the specification's own embodiment language (receive request at first computing device placed by user at second computing device → research a plurality of media playlists at a plurality of media communities → select playlists having the media content → transmit to second computing device), and is tentative.

2. U.S. patent references cited on the face of US 10,491,646 B2 (partial list, in citation order)

For each: full citation (as far as verifiable), date, brief description, and potential § 102 mapping. Where the USPTO snippet did not show a title, I have not guessed at an exact title; I describe only what is supported by the classification codes printed in the same snippet plus known art area, and I mark confidence.

3. Overall § 102 assessment (tentative)

• Claim 1 core elements (per the specification's method embodiment): (a) receiving at a first computing device a request relating to media content placed by a user at a second computing device; (b) researching a plurality of media playlists at a plurality of media communities; (c) selecting playlists having the media content; (d) transmitting them to the second computing device.
• The cited references cluster in single-service music/library playlist-generation and management art (Pezzillo, Swenson, Oppenheimer, Gopinath, Weare, Platt, Volk). They are strong § 103 candidates against the "receive-request → select existing playlists containing the item → transmit" elements.
• The element most likely to defeat solo § 102 anticipation — and the feature the '646 specification markets as its improvement — is "a plurality of media communities" (i.e., searching playlists residing in multiple distinct online media communities/networks, e.g., Spotify, YouTube, SoundCloud) and returning pre-existing playlists (as opposed to auto-generating a new playlist). None of the ten references, based on the verifiable bibliographic/classification data alone, is shown to teach that combination; I cannot identify any single cited reference that clearly anticipates claim 1 on the evidence retrieved.
• For dependent claims directed to sorting by user preference, sharing via email/text/posting, and playing/displaying via a media player, the Microsoft-line playlist-management references (Swenson 7,254,618; Platt 2003/0221541) are the most likely § 102 candidates, subject to verification of their full texts.

4. Explicit statements of uncertainty (per operating rules)

1. The complete citation list was not retrieved — the USPTO PDF snippet ends at US 2004/0019497 A1 with a "(Continued)" marker. Foreign patent documents and NPL ("Other Publications") may be cited on the face of the patent but were not visible in my retrieved material. This analysis covers only the ten U.S. references shown.
2. I did not verify exact titles or full disclosures of the individual references this session; descriptions above are limited to what is supported by the printed inventor/date/classification fields, plus general knowledge of the art area, and are labeled with confidence levels.
3. The issued claim text of the '646 patent was not independently verified in this session (per the earlier summary), so the § 102 claim mapping is based on the claim elements as summarized from the specification and is provisional.

If you can provide the remaining pages of the USPTO PDF (References Cited continuation + claims), I can complete the per-claim § 102 analysis for every reference, including any foreign and non-patent literature.

The user references a "Prior Art section of this page," but the provided page content does not include any prior-art section or cited references. I will locate the actual prior-art record (examiner-cited references from the '646 patent and its family) and then build the § 103 analysis on verified references.

Important preliminary flags

Before giving the § 103 analysis, three caveats must be stated plainly:

1. No prior-art section was provided in the page content. The user message references "the Prior Art section of this page," but the supplied Google Patents excerpt contains no "Citations"/"Patent Citations" or prior-art listing. My additional searches (capped by tool limits) returned only the patent's own text and a cross-citation from US20060032363 pointing to the parent patent US 9,225,580 — not the examiner's cited art for the '646 patent.
2. The exact claim language is unverified. As flagged in the earlier patent summary, the issued claim set (18 claims) could not be confirmed verbatim. A third-party litigation analysis of Dynamuse v. iHeartMedia (W.D. Tex. 7:26-cv-00116) describes asserted claim 1 as containing UI limitations — displaying an interactive UI while playing a media item, facilitating selection of a "playlist assistance function," and returning "exactly matched" results as a "final output without any recommendations or suggestions." That source is unverified. An obviousness analysis is only as good as the claim construction, and every conclusion below is contingent on the actual claim text.
3. The controlling priority date is February 29, 2012 (provisional 61/605,090), so prior art must predate that date (or the Feb. 27, 2013 non-provisional filing, if the provisional is not fully supported) to qualify as § 103 prior art.

Given those constraints, what follows is a framework plus the most defensible combinations, with confidence labels. It should be re-run against the file wrapper (which will list the examiner's actual cited references) and the issued claims before being used in any substantive filing.

A. Claim scope (as best understood from the specification and abstract)

The core claimed method (per the Abstract and spec at col. 1-2 and the "Some embodiments" paragraphs) is:

• Receiving, at a first computing device (server), a request relating to media content, the request placed by a user at a second computing device (client);
• Researching a plurality of media playlists at a plurality of media communities for the media content;
• Selecting one or more media playlists (at one or more communities) having the media content;
• Transmitting the selected playlists from the server to the client device.

Dependent concepts disclosed: evaluating the request (song/artist/genre vs. sort preference), sorting results by user preference, sharing via email/text/social posting, displaying/playing via a media player, and network types (LAN/WAN/MAN/PAN/Internet/cloud).

Analytically, this is a "reverse playlist lookup" system — given a media item, return all playlists (across multiple online communities) that contain it. The "problem" the patent itself states is that "conventional systems do not provide any technique for the user to know [and] find that playlist without having to individually go through every single playlist in the library."

B. The § 103 framework and the relevant PHOSITA

A person of ordinary skill in the art (circa 2012) would be a software engineer working on media-player applications, digital-media libraries, or music-streaming/social-music services, familiar with client-server architectures, web APIs, playlist data structures (playlist = ordered list of media identifiers/metadata), and social-network/music-community integration. The engineering difficulty of the claimed invention is low-to-moderate: the elements are standard database indexing, query, and presentation operations applied to playlist metadata.

Under KSR Int'l Co. v. Teleflex Inc. (2007), obviousness can be shown where prior art elements perform the same function and a PHOSITA would have had reason to combine them with a reasonable expectation of success — especially where the combination is "the predictable use of prior art elements according to their established functions" and the invention is "a combination of familiar elements according to known methods."

C. Prior-art categories that map element-by-element (high-confidence, pre-2012)

These are well-documented, verifiable systems/features in existence before Feb. 29, 2012:

What is comparatively novel (and the § 103 battleground) is the specific combination: a server-side, cross-community aggregated reverse playlist lookup — i.e., applying the familiar local "which of my playlists has this song" search across playlists held at multiple independent online media communities, and returning those community playlists to the client.

D. Proposed § 103 combinations and motivation

Combination 1 — Local playlist reverse-lookup + multi-service aggregation (the strongest theory)

Primary reference: A local media-library manager disclosing reverse playlist lookup (e.g., Apple iTunes/iPod-library search where a track is looked up and the user is shown every playlist containing it; equivalents in Windows Media Player, Winamp, MediaMonkey). This teaches the user-facing concept and the underlying query (track identifier → set of playlists).

Secondary reference: An online media/music-community service with server-side user playlists and API-based access (e.g., Spotify, SoundCloud, or a cloud music-locker service with server-stored playlists). This teaches storing playlists at a network community and serving them to client devices.

Tertiary reference (the aggregation step): A social/aggregation platform or media-community portal that accesses multiple third-party music services and consolidates a user's content (e.g., 2011-era Facebook music integrations with Spotify/Rdio; any "manage all my music services from one pane" tool). This teaches interacting with a plurality of media communities through one interface.

Element mapping: (i) request received at server — the aggregation server receives the user's selection/query from the client; (ii) researching a plurality of playlists at a plurality of communities — the aggregation server queries each connected community's playlists (indexed by track) for the selected media item; (iii) selecting playlists having the content — filtering query hits; (iv) transmitting results to the client — returning the matched playlist list for display.

Motivation to combine (articulated, not conclusory):

• A PHOSITA designing a "playlist assistant" would recognize that the local-library reverse-lookup interaction users already knew from iTunes could be preserved when the user's playlists migrate to cloud/music-community servers — the entire industry (Apple iCloud, Google Music, Amazon Cloud Player) was migrating local libraries to server-side playlists in 2011, creating a direct incentive to re-implement familiar local-library features against server-side data.
• Once a user's playlists live in multiple communities (e.g., a Spotify playlist, a YouTube playlist, a SoundCloud set), the same user-facing question ("where is this song?") naturally extends to a query across all of them; aggregating the lookup is the predictable application of the aggregation logic already used to give users a unified view of their accounts.
• The result is predictable: query each community's track→playlist index, union/filter the hits, return the list. No unexpected technical hurdle — standard web-service fan-out and result merging.

Weakness: If claim 1 requires the UI-specific limitations ("displaying an interactive user interface while playing," "exactly matched final output without recommendations"), Combination 1 needs a reference disclosing the contextual, while-playing invocation (request generated from the currently playing item without interrupting playback). That nuance may be the differentiator the drafter added to survive this obviousness attack — hence the need to verify claim 1.

Combination 2 — Audio-recognition/identification prior art (for any audio-recognition-dependent claims)

If any claim covers recognizing a song playing through an external speaker and then locating it in playlists, the primary reference would be a fingerprinting/recognition service (Shazam, SoundHound, Gracenote, Google "search by song," all pre-2012), combined with the playlist-lookup art of Combination 1. Motivation: recognition services already returned "identify + buy + find related content"; adding "show my playlists containing this track" is the same predictable augmentation. Note the spec itself describes this as "audio recognition-based sharing."

Combination 3 — Social sharing/messaging art (for sharing-dependent claims)

Any dependent claim reciting sharing via e-mail/text/social posting maps onto ubiquitous pre-2012 social-music sharing (Facebook music ticker, Spotify/Twitter integration, "share song" email links from iTunes/MySpace). These are purely conventional; motivation is self-evident (user virality). These claims are weak against § 103 if Combination 1's base is established.

Combination 4 — Sorting/modifying results (for the dependent claims)

User-preference sorting of result lists and playlist editing (delete/move/shuffle) were stock features of media libraries and web UIs pre-2012 (iTunes sorting/editing; any Ajax result-list sorter). Adding these to Combination 1 is "obvious to try"/"predictable variation" under KSR.

E. Why the aggregation step is the crux — and the counterarguments

The patentee's likely non-obviousness arguments are: (1) prior-art local reverse lookup was within a single library, whereas the claims require a plurality of media communities; and (2) no single pre-2012 reference taught a server that indexes playlists across independent, third-party communities and returns community playlists. Under KSR, however, claim 1 would survive only if the multi-community research step was not merely the predictable combination of known elements serving known functions. A defendant would argue: "Given a user with playlists on Spotify, YouTube, and SoundCloud, and a known single-community reverse-lookup query, extending the same query to all three communities via their existing APIs is an obvious design choice — it requires no inventive skill, only fan-out." That argument is strong if the claim's only non-conventional element is the word "plurality."

Counterweights the patentee would raise: (a) "researching a plurality of media playlists at a plurality of media communities" may require a pre-built, cross-community index with metadata normalization across heterogeneous services — a non-trivial engineering problem if the claims are construed to require searching community servers that do not expose a unified query API; (b) any "final output without recommendations" limitation, if real, is a deliberate disclaiming of the recommendation/auto-playlist art (e.g., Apple Genius, auto-playlist generators) and narrows the obviousness case by excluding the closest prior art that mixes recommendations with playlist generation.

F. Secondary considerations

• No objective indicia are in the record before me. There is no evidence of long-felt need, industry praise, copying, or commercial success attributable to the claimed feature. The specification's own "background" admits the problem but the record does not show failed attempts by others. Absent such evidence, secondary considerations are unlikely to rescue the claims if the primary combination is made out.
• The fact that the claimed feature (finding where a song lives across your playlists) is now implemented as a basic user convenience in streaming apps (search returns "in which playlists does this appear") suggests the idea was a natural, expected evolution rather than a paradigm shift — though post-priority-date implementations cannot themselves be prior art and are mentioned only as contextual evidence of obviousness-in-hindsight discipline.

G. Bottom line and recommended next steps

1. Most plausible § 103 theory: Local-library reverse playlist lookup (iTunes-class media managers) + server-side playlists of online music communities (Spotify/SoundCloud/cloud-locker class) + cross-service aggregation/user-account consolidation (social-music-integration class), with conventional networking, sorting, and sharing. A PHOSITA would combine these to preserve a familiar local-library interaction as users' playlists migrated to multiple cloud communities — a predictable combination with a reasonable expectation of success.
2. The analysis is contingent on (a) the issued claim text, which I could not verify, and (b) the actual examiner-cited references, which were not in the provided page and could not be retrieved within tool limits. If the UI/contextual "while playing" and "exactly matched results, no recommendations" limitations are in independent claim 1 as the third-party litigation analysis suggests, the obviousness case weakens materially and depends on finding a single system that invoked playlist lookup contextually from a playing track across multiple communities.
3. Must-do before use: Pull the USPTO file wrapper for US 10,491,646 (and parent 9,225,580) to obtain the examiner's § 102/103 references; obtain the verified claim set; and then map each claim element to the specific cited art with pinpoint citations. In the pending Texas litigations (e.g., 2:25-cv-01110 through -01114; 7:26-cv-00116; 3:26-cv-00803), the defendants' forthcoming invalidity contentions/IPR petitions will be the best source of the concrete art to compare against.

Confidence summary: High confidence in the § 103 framework, element mapping to generic pre-2012 product categories, and motivation analysis. Low confidence in identifying the specific examiner-cited references or in opining on the exact claim 1 limitations — those items remain unverified and are explicitly flagged rather than assumed.