US 8473553

I'll search for authoritative information on US 8473553, including any CAFC/litigation activity.

Let me run more targeted searches for this exact patent number.

Summary: US Patent No. 8,473,553

Source of record: Full patent text from Google Patents (https://patents.google.com/patent/US8473553/en), fetched 2026‑09‑24. My USPTO/CAFC web searches on the exact number returned no independent docket hit, so I rely on the authoritative patent text and flag uncertainties explicitly below.

Bibliographic data

Abstract (verbatim)

A computer‑implemented method includes sending an instant message communication from a first device of a first person to a plurality of other persons in a topic‑based community, and receiving a number of instant message communications at the first device. The method further includes placing each of the response instant message communications in a separate display that is viewable by the first person, and sending a second instant message communication from the first device of the first person to the plurality of other persons after a certain number of response instant message communications have been received by the first device from the plurality of other persons, wherein the second instant message communication is an indication that the first person is satisfied with at least one of the response instant message communications.

Important observation: The issued independent claims (1, 5, 8, 12) are not directed to the "satisfaction message" concept that dominates the abstract and the BRIEF SUMMARY. Instead, the granted independent claims are directed to merging private one‑on‑one response threads into a shared "merged threaded view," while allowing a responder to block ("prevent") its private thread from being merged. The "second instant message … satisfied" feature appears only as a dependent limitation (claim 2). The specification supports both themes (see the discussion of blocks 152–176 and FIG. 2), so the claims and the written description are internally consistent, but a reader should not assume the abstract describes the claim scope.

Plain‑language overview of the independent claims

Claim 1 — Computer‑implemented method (thread merging with a responder‑controlled opt‑out)

• A first person (User A) sends an instant message to many people in a topic‑based community.
• User A's device receives responses that respectively form private IM threads between each responder and User A.
• Once those private threads are initially visible to User A, they are merged into a single "merged threaded view" visible to User A and to the other persons.
• Exception: if a particular responder elects to prevent it, that responder's identified private thread is kept out of the merged view.
• Both the private threads and the excluded thread remain immediately and automatically available to User A without needing any permission to view/access them.
• The excluded thread corresponds to the responder who opted out.

Claim 5 — Computer program product

• A non‑transitory computer‑readable storage medium with instructions that, when executed by a first device, cause that device to perform the same method steps as claim 1 (send → receive private threads → merge → prevent an identified thread from merging on that responder's election → immediate/automatic availability to the sender).

Claim 8 — Computer system

• A system with a central processing unit configured to perform the same functional sequence as claim 1 (send community IM; receive responses forming private threads; merge into a shared merged threaded view; honor a particular responder's election to exclude its identified thread; keep both the private threads and the excluded thread immediately/automatically available to the sender without a permission requirement).

Claim 12 — Electronic instant messaging method (question/answer framing + separate initial displays)

• Sends an IM in the form of a question from a first person's device to multiple other persons.
• Receives responses forming private threads between each responder and the sender.
• Initially places each response in a separate display viewable by the sender.
• Then merges the private threads into a merged threaded view visible to the sender and the other persons.
• Prevents an identified thread from being merged when that responder elects to prevent it, with both the private threads and the excluded thread remaining immediately/automatically available to the sender without needing permission to view/access them.

Dependent claims worth noting: claim 2 (question/answer framing; separate initial display; the sender sets a maximum number of responses and sends the "satisfied" second IM after that maximum is reached); claim 3/7/10 (further back‑and‑forth communications placed in separate displays); claim 4 (the excluded thread is viewable by the sender and that responder only, whereas the merged view is viewable by all); claim 6 (question/answer form); claim 9 (question/answer form); claim 11 (send second IM indicating satisfaction).

Litigation / CAFC check — with stated uncertainty

• No CAFC 2026 docket or district‑court action specifically asserting US 8,473,553 was found in my searches. I therefore cannot confirm any pending or decided 2026 appellate activity for this exact patent, and I will not infer one.
• Searches surfaced a different patent in Snap‑related appeals — U.S. 8,489,599 — at issue in Xerox Corp. v. Snap Inc., Fed. Cir. Nos. 23‑1983/1985/1988/2028, PTAB IPR2021‑00987/01294/01458, with a nonprecedential opinion dated 2025‑07‑24 (https://www.cafc.uscourts.gov/opinions-orders/23-1983.OPINION.7-24-2025_2549246.pdf). This is not patent 8,473,553 and should not be conflated with it. I did not find evidence that 8,473,553 was part of that appeal.
• The Google Patents record shows prosecution/property history only (IBM → Snapchat → Snap assignments; maintenance fees at years 4, 8, and 12) — no litigation events listed.

If you need a definitive litigation status, the authoritative checks would be the USPTO PatentCenter/Assignment records for 12/388,997 and a purpose‑built PACER/CourtListener docket query for "8,473,553" — which my current search tools did not expose as a separate confirmation.

I'll search multiple litigation-focused sources for this exact patent number.

Those returned irrelevant hits. Let me query litigation-specific databases directly.

Let me try more specific litigation databases and dockets directly.

Litigation Search Result for U.S. Patent No. 8,473,553

Bottom line

No litigation involving U.S. Patent No. 8,473,553 was found. My targeted searches of litigation-focused sources returned zero hits tying this specific patent number to any federal district court case, ITC investigation, PTAB proceeding, or Federal Circuit appeal.

What I searched and what I found

Note: my final three searches (CourtListener, the Unified Patents portal, and a combined infringement query) were cut off by a step-limit before returning results, so those specific avenues are unexhausted. I flag that as a gap, not as a clean negative.

Important distinction — do not conflate these with 8,473,553

Searches surfaced several Snap-related cases that are frequently confused with the patent at issue (consistent with the prior section's warning):

• Xerox Corp. v. Snap Inc., Meta Platforms, Inc., X Corp., Fed. Cir. Nos. 2023‑1983/1985/1988 (nonprecedential, decided July 24, 2025), on appeal from IPR2021‑00987/01294/01458 — concerns U.S. 8,489,599, not 8,473,553. (opinion)
• Vaporstream, Inc. v. Snap Inc., No. 2:17‑cv‑00220‑MLH‑KS (C.D. Cal.) — concerns the Vaporstream "reduced traceability" family (e.g., 8,935,351; 10,412,039), not 8,473,553.
• Dolby Video Compression LLC v. Snap Inc., No. 1:26‑cv‑00317‑JLH (D. Del., filed Mar. 23, 2026) — concerns video-coding patents, not 8,473,553.

None of these asserts U.S. 8,473,553.

Why this is a plausible (but unconfirmed) negative

The Google Patents record for US 8,473,553 lists no litigation or PTAB events — only prosecution/assignment history (IBM → Snapchat, Inc., recorded 2016‑01‑22; name change to Snap Inc., recorded 2018‑12‑06) and maintenance-fee payments at years 4, 8, and 12 (last paid 2024‑12‑10). See https://patents.google.com/patent/US8473553/en.

The patent was transferred to Snap in late 2015 and is currently owned by Snap Inc. An owner-operated patent (rather than one held by a non-practicing entity) with no recorded enforcement events is consistent with — though not proof of — a no-litigation status.

Confidence level and caveats

• Confidence that no litigation exists: moderate, not high. My searches strongly support a negative, but I was unable to complete exhaustive docket queries.
• Unverified assumptions I am not treating as fact: that the patent has never been litigated. A clean negative requires database access my tools did not reliably provide.

To obtain a definitive answer, run these exact-number checks:

1. USPTO PatentCenter / Patent Assignment Search for application 12/388,997 (look for § 325(d) / Rule 290 notice-of-suit filings).
2. CourtListener / RECAP full-text query for "8,473,553" and "8473553" — this catches assertions buried in complaints and IPR papers.
3. Unified Patents litigation portal (https://portal.unifiedpatents.com/litigation/caselist) — search the exact number.
4. PACER docket search across all districts (a patent can be asserted in a complaint that names dozens of patents, so full text is essential).
5. PTAB / Docket Alarm / insight.rpxcorp.com for any IPR, PGR, or reexam.

If you can grant me additional search steps, I will complete items 2 and 3 and report back.

I'll verify the canonical "no proceedings on file" result against public sources before finalizing.

Proceedings overview

Zero AIA trial proceedings on file. The canonical USPTO Open Data Portal (ODP) "PTAB proceedings on file" block for US 8,473,553 is empty (0 active, 0 claims invalidated, 0 claims sustained, 0 settled, 0 institution denied), and my independent web sweeps surfaced no IPR, PGR, or CBM naming this patent — so the defensive posture is not "the patent is hardened" but rather "untested and unhardened, and therefore still fully attackable: all 12 claims stand exactly as they issued on 2013-06-25, with no estoppel, no adverse FWD, and no PTAB-construed claim scope to constrain either side."

Verification performed (and its limits)

I treated the structured ODP block as canonical per the operating rules, then tried to falsify it:

Confidence statement: I am highly confident there is no IPR/PGR/CBM on 8,473,553. I am not in a position to rule out a recently filed, not-yet-indexed petition, because my tools did not expose a live PTAB E2E / Docket Alarm docket for 12/388,997. The gap is small (a petition filed within the ODP ingest lag) but I will not paper over it.

Adjacent proceedings that are NOT this patent (do not conflate)

These showed up repeatedly in searching and are the most likely source of confusion in a demand-letter or due-diligence context:

I flag the 8,489,599 item explicitly because it is the single most likely mis-citation a defendant will encounter when a vendor or AI-assisted search tool runs "Snap + IPR + 8,4__3,5__."

---

Strategic summary

Claim status: everything is UNTESTED. No claim of US 8,473,553 has been canceled, confirmed, or construed by the PTAB. Contrast this with the four independent claims' subject matter — the merging of private one-on-one IM threads into a shared view with a responder-controlled opt-out (claims 1, 5, 8, 12, per the issued claim text in the authoritative patent record). Because no tribunal has construed "merged threaded view," "immediately and automatically available … without requiring permission," or the opt-out limitation, claim scope is whatever the patent owner asserts plus whatever a district court construes — there is no PTAB record to anchor a § 112 indefiniteness or § 103 obviousness attack, and equally no IPR estoppel to inherit.

Estoppel landscape: clean slate, and that cuts both ways. Because no IPR was ever filed, § 315(e)(2) estoppel has never attached to anyone — not to Snap (whose prior IPR activity was against Vaporstream, as petitioner on different patents), not to any prior accused infringer. The practical consequence for a current defendant: you are not blocked by anyone else's IPR, but you also cannot free-ride on anyone else's win. Every ground — every prior-art combination, every § 112 theory — is available to you in district court or in a fresh petition. Note the flip side: if you file first, you absorb the estoppel, and any co-defendant who does not join remains free to re-raise grounds (exactly the argument that defeated a stay in the PARC matter, quoted in the sources above).

Pattern signals: none on this patent. No serial petitioner, no patent-owner appeal, no Unified Patents (or other defensive aggregator) in the chain. The only recorded events are administrative: IBM → Snapchat assignment (recorded 2016-01-22, effective 2015-12-16), Snapchat → Snap Inc. name change (recorded 2018-12-06, effective 2016-09-23), and maintenance fees paid at year 4 (2017-01-10, with a late-payment surcharge), year 8 (2020-11-24), and year 12 (2024-12-10). Adjusted expiration is 2030-06-05 — roughly 3 years 8 months of remaining statutory life as of today (2026-09-29), which is a short enough runway that a defendant should weigh IPR cost against settlement leverage carefully.

What the absence actually signals. The prompt's premise — "well-asserted patents eventually attract IPRs" — is not met here, because there is no evidence in the sources I reviewed that 8,473,553 has been asserted at all. It appears to have moved to Snap as part of an IBM portfolio divestiture and to be sitting in a defensive stockpile. That is materially different from "asserted and survived." A patent that has never been tested is not a strong patent; it is an unquantified one, and its owner has no litigation track record to point to.

---

Recommended next steps

If you are a defendant facing an assertion of 8,473,553:

1. Do not be deterred by "Snap owns it." Snap's PTAB track record on messaging patents (Vaporstream, PARC) reflects Snap as a petitioner; there is no record of Snap defending this patent. There is no FWD, no institution decision, and no claim construction for you to work around.
2. Attack the claim draft directly. The independent claims (1, 5, 8, 12) turn on a bare-bones sequence: send community IM → receive private threads → merge into a shared view → honor a responder opt-out. That is a functional, result-oriented recitation with no algorithmic detail, and the "immediately and automatically available … without requiring permission" language is a prime § 112(b) indefiniteness candidate. Neither theory has been tested.
3. Mine the pre-2009 art space thoroughly. The patent's own cited-art list is unusually thick with on-point references: AOL's "Displaying complex messaging threads into a single display" (US 2007/0282956 A1), IBM's "System and method for multi-threaded discussion within a single instant messenger pane" (US 2006/0059235 A1) and "Method and interface for multi-threaded conversations in instant messaging" (US 7,475,110 B2), Jacquette's "Multi-threaded instant messaging" (US 2008/0028027 A1), and IBM's "System and method for correlating questions and answers in an instant messaging environment" (US 2010/0023586 A1). A § 103 combination built from the multi-threaded-IM pane references plus a community/broadcast-question reference (e.g., US 5,828,839 or US 6,519,629) is the natural starting point — and, critically, nobody has ever tried it.
4. Calendar the one-year bar. If the complaint was served and you intend to petition, § 315(b) gives you 12 months from service; the FWD is then due within 12 months of institution (§ 316(a)(11)). Because there is no prior petition on this patent, you face no § 325(d) "substantially the same art" risk — you get the first clean shot at the Board.

If no litigation exists and you are doing diligence: the correct finding for your memo is "no PTAB proceedings of record for U.S. 8,473,553 as of 2026-09-29," cited to the empty ODP block, with the caveat that this reflects an unjuried patent rather than a vindicated one. Do not describe it as "survived IPR" — that would be inaccurate.

To close the residual verification gap (recommended once, if the stakes justify it):

• USPTO PTAB E2E / Patent Trial and Appeal Board End-to-End system: https://ptacts.uspto.gov/ptacts/ — search Application No. 12/388,997 and Patent No. 8,473,553.
• USPTO PatentCenter for prosecution and assignment history of 12/388,997.
• CourtListener full-text docket search for "8,473,553" and for 12/388,997: https://www.courtlistener.com/.

No proceeding numbers have been invented in this report. Where the record is empty, I have said so and described the boundary of my verification rather than filling the space with an inference.

Assignment / Ownership-Chain Analysis — US Patent No. 8,473,553

Method note & sourcing. USPTO Assignment Center (https://assignmentcenter.uspto.gov/) was not directly queryable with the tools available, so the chain below is reconstructed from (a) the authoritative Google Patents legal-events record for US 8,473,553 (https://patents.google.com/patent/US8473553/en), and (b) corroborating 37 CFR 3.73(b) chain-of-title statements filed in other Snap applications that cite the same reel/frame, which independently confirm the IBM → Snapchat link. Where a field (notably the recording correspondent) is not in the record I could retrieve, I say so rather than inventing it. No contradiction with the previously generated summary/litigation sections: both prior sections correctly found no enforcement events, and this section is consistent with that.

---

Inventors

• All three executed an ASSIGNMENT OF ASSIGNORS' INTEREST to IBM, executed 2009-02-18, recorded 2009-02-19 (Reel 022284/0073) — the standard IBM employee-inventor form that conveys "the entire worldwide right, title, and interest" to IBM at filing.
• Unusual-pattern check — not present. There is no evidence any inventor departed IBM within 12 months of filing, and no evidence of a post-filing re-assignment back to the inventors. The absence of a fire-sale tell is reinforced by the fact that the asset stayed with IBM for ~6 years 10 months after filing before any transfer (see timeline). I could not independently verify each inventor's job title/location from the record retrieved, so the "IBM employee" inference rests on the assignment document, not on a separate employment source.

---

Original assignee

International Business Machines Corporation (IBM) — named on the issued patent; New York corporation, place of business Armonk, NY.

• Primary line of business: enterprise computing, software, and services. Relevant to this patent's subject matter, IBM was the vendor behind Lotus Sametime / Lotus Notes community messaging, i.e., a real product family in the community-based instant-messaging space (the field of the claimed subject matter). I flag that I did not verify whether Sametime/Notes actually practiced the specific granted claims (the merging/opt-out threading features), so "ships a product embodying the claims" is plausible but not confirmed.
• Status: operating, publicly traded (NYSE: IBM); not acquired, not dissolved, not in bankruptcy.
• IBM is, separately, a prolific patent seller; a transfer of a patent out of IBM is routine corporate IP monetization and is not, by itself, an NPE signal.

---

Assignment timeline

Two recorded patent assignments plus one change-of-name were found. Frame spans confirm this was a batch/portfolio transfer, not a single-patent deal: the IBM→Snapchat recording occupies Reel 037573, Frames 0170–0192 (23 frames), covering multiple IBM patents in one instrument.

1. 2009-02-18 (executed) / recorded 2009-02-19 — Reel 022284/0073

   • Conveyance: Assignment (ASSIGNMENT OF ASSIGNORS' INTEREST)
   • Assignor: Michelle McDevitt; Josef Scherpa; Andrew L. Schirmer
   • Assignee: International Business Machines Corporation (Armonk, NY)
   • Correspondent: not stated in the record retrieved. (No recurrence to flag.)
   • Context: Routine inventor-to-employer assignment executed at filing; keeps title with IBM.

2. 2015-12-16 (executed) / recorded 2016-01-22 — Reel 037573/0170 (Frames 0170–0192)

   • Conveyance: Assignment (entire interest)
   • Assignor: International Business Machines Corporation
   • Assignee: Snapchat, Inc. (California / Delaware corporation)
   • Correspondent: not confirmed on the patent record I could retrieve. Note: Snap's parallel 2016 trademark change-of-name recording (Execution Date 2016-09-23, recorded 2017-01-03, Reel 5959/0348) lists Jennifer D. Arkowitz, Kilpatrick Townsend & Stockton LLP, 1100 Peachtree St., Suite 2800, Atlanta, GA 30309 as correspondent. That is a large general-practice IP firm doing routine Snap prosecution/trademark work — a single appearance is not a finding, and I cannot confirm whether that firm also filed this patent assignment. Flagged, not concluded.
   • Context: Portfolio acquisition — Snapchat acquired a package of IBM patents; the 23-frame span shows multiple assets recorded together.

3. 2016-09-23 (executed) / recorded 2018-12-06 — Reel 047690/0016

   • Conveyance: Change of Name (only)
   • Assignor: Snapchat, Inc.
   • Assignee: Snap Inc.
   • Correspondent: not stated in the record retrieved.
   • Context: Change of name only (corporate rebrand Snapchat, Inc. → Snap Inc., effective 2016-09-23). No change in beneficial ownership.

Post-transfer maintenance: fees paid at years 4 (2017-01-10, with a late-payment surcharge), 8 (2020-11-24), and 12 (2024-12-10) — all as large entity, consistent with an operating-company (Snap Inc.) owner. Adjusted expiration 2030-06-05. No security agreements, licenses, releases, or corrective assignments are recorded.

---

Timeline diagram

timeline
    title Ownership of US 8473553
    2009 : Filed by McDevitt Scherpa Schirmer
         : Assigned to IBM
    2013 : Patent issued
    2015 : IBM assigns to Snapchat Inc
    2016 : Snapchat renamed Snap Inc
    2024 : 12th year maintenance fee paid

---

NPE / troll-pattern signals

---

Verdict

Defensive / non-asserting — with an explicit definitional caveat.

The five prescribed labels do not perfectly fit the facts: this patent is neither NPE-held nor held by a defensive aggregator. It sits with an operating company (Snap Inc.) and has never been asserted. I select Defensive / non-asserting as the closest fit because the chain is demonstrably non-asserting — the only enforcement-relevant fact in the record. Justification: the chain is IBM (Reel 022284/0073, 2009-02-18) → Snapchat, Inc. (Reel 037573/0170, executed 2015-12-16, a 23-frame batch/portfolio assignment) → Snap Inc. (Reel 047690/0016, a change of name only, 2016-09-23). Every link is between real operating corporations; there is no shell LLC, no known asserter, no cascading transfers, no pre-suit transfer, and no bankruptcy. Accordingly, no NPE-troll pattern is present on this record.

Confidence: High that no NPE pattern exists (zero of the eight signals are affirmatively present; one is merely unverifiable). Lower confidence on the recording correspondent, which I could not retrieve.

To verify / complete:

1. USPTO Assignment Center — https://assignmentcenter.uspto.gov/ (and https://assignment.uspto.gov/patent/index.html) — search by patent 8,473,553 or app 12/388,997; pull the Assignment Abstract of Title to capture the correspondent of record for Reels 022284/0073, 037573/0170, and 047690/0016 (the one field still open).
2. USPTO PatentCenter for app 12/388,997 — check for Rule 290 / §325(d) notice-of-suit filings (would supersede the "non-asserting" call).
3. SEC EDGAR — IBM 10-K/10-Q disclosures and Snap Inc. (S-1, 2017) IP disclosures, to corroborate the 2015-12-16 portfolio purchase and confirm no assertion obligation attached.

I'll verify the citation data for US 8,473,553 and its cited references through targeted searches, then map each reference to the claims it could anticipate.

I have strong data on several references. Let me verify a few more of the high-relevance citations.

Prior-Art Analysis — U.S. Patent No. 8,473,553

Analysis date: April 26, 2026 · Patent under review: US 8,473,553 B2 (the exact number requested — see the disambiguation note below)

---

0. Confirmation of the patent and a disambiguation warning

The record I retrieved confirms the exact identifier 8,473,553:

Two warnings required by the "interpret identifiers literally / don't auto-correct" rule:

1. Do not conflate with US 8,473,552. A search hit surfaced "IPR2016-01146 — Inter Partes Review of U.S. Pat. 8473552" (a Microsoft IPR). That is a different patent with a nearly identical number. It is not the patent at issue and is excluded from this analysis.
2. My tools do not expose the USPTO PatentCenter interface directly; the citation list below is taken from the authoritative full text of US 8,473,553 (which reproduces the USPTO "References Cited" data on the face of the patent). Where I could independently corroborate a reference on the open web, I did so and say so.

---

1. Legal framework applied

• Pre-AIA § 102 controls. Application 12/388,997 was filed 2009-02-19, before the AIA first-to-file date of 2013-03-16. The governing paragraphs are pre-AIA § 102(a) (known/published before the invention date), § 102(b) (published more than one year before filing, i.e., before ~2009-02-19), and § 102(e) (U.S. patents/applications filed before the applicant's filing date but published later).

• Anticipation is strict. A reference anticipates a claim only if it discloses every element of that claim, arranged as in the claim, in a single reference. A reference that teaches only the preamble or a subset of elements is at best § 103 obviousness art, not § 102 art.

• Critical consequence for this patent: every claim of US 8,473,553 is either independent (1, 5, 8, 12) or depends from an independent claim. Therefore, to anticipate any claim of this patent, a reference must disclose all of the following in one document: (i) one-to-many community IM broadcast; (ii) responses forming private one-on-one threads; (iii) merging those private threads into a shared view; (iv) a responder-controlled opt-out ("prevent … from being merged"); and (v) the private + excluded threads being immediately and automatically available to the sender without requiring permission.

  No reference cited in US 8,473,553 discloses element (iv) or element (v). As detailed below, no cited reference anticipates any claim of US 8,473,553 in its entirety. The citations are, however, highly relevant § 103 art and many come very close element-by-element. This is consistent with the observation (from the earlier section) that the point of novelty in the granted claims is the responder-controlled merge opt-out, not the "satisfaction message" of the abstract.

The table in § 3 therefore reports the closest potential § 102 mapping, with the honest caveat that full-claim anticipation is not established.

---

2. The full "References Cited" list of US 8,473,553 (35 entries)

Dates below are Priority date / Publication date as printed on the patent's face. § 102(b) references are those published before 2009-02-19; § 102(e) references are those filed before 2009-02-19 but published later.

(Entries #34–35 have publication dates after the 2009-02-19 filing but were filed in 2008, so they qualify only as pre-AIA § 102(e) art.)

---

3. Tier 1 — Most relevant referenced prior art (detailed)

3.1 US 2004/0019637 A1 — IBM "SkillTap"

• Full citation: U.S. Patent Application Publication 2004/0019637 A1, "Interactive one to many communication in a cooperating community of users," Goodman, Van der Meulen, Wu, Stewart, Lagarde; assignee IBM.
• Dates: filed 2002-07-26; published 2004-01-29. (§ 102(a) and § 102(b) art.)
• Description: A requester's IM is published via a pub/sub service to an entire community of subscribers ("SkillTap bot"). Listeners re-ceive the request as an IM alert and may respond; "the requester receives IM's from each responder in separate windows." Message throttles "limit number of listeners engaging the requester."
• Potential § 102 mapping: Discloses the one-to-many community broadcast and separate per-responder response windows elements. It maps onto the preamble and first two elements of claims 1, 5, 8, 12 and the separate-display step of claim 12. It does not disclose private-thread formation as a claim limitation, the merging step, the responder opt-out, or the no-permission availability feature. No full-claim anticipation. Best used as § 103 primary art for the community-broadcast elements.

3.2 US 7,475,110 B2 — IBM (multi-threaded IM; merge option)

• Full citation: U.S. Patent 7,475,110 B2, "Method and interface for multi-threaded conversations in instant messaging," Kirkland et al.; assignee IBM.
• Dates: filed 2004-01-07; granted 2009-01-06. (§ 102(a)/(b) art.)
• Description (corroborated on the open web): Provides a menu option to start a new topic, creating a segregated thread in the messaging window for all parties, and — directly on point — "a menu option may be provided by the instant messaging application to allow a user to merge one or more of the threaded conversations into a single conversation."
• Potential § 102 mapping: The closest art on the "merging … into a merged threaded view" element of claims 1, 5, 8, 12 and on the multiple-thread display of claims 3/7/10. Because the sender controls the merge and there is no responder opt-out and no "immediately/automatically available without permission" teaching, it cannot anticipate the independent claims in full.

3.3 US 2006/0059235 A1 — IBM (multi-threaded discussion in a single IM pane; session limit)

• Full citation: U.S. Patent Application Publication 2006/0059235 A1, "System and method for multi-threaded discussion within a single instant messenger pane," assignee IBM.
• Dates: filed 2004-09-15; published 2006-03-16. (§ 102(a)/(b) art.)
• Description (corroborated): Allows an unlimited number of conversation threads inside one IM session window, each thread in its own area; the user configures a maximum number of concurrent sessions and an automatic message ("I'm busy right now, want to join the queue?") sent when the limit is reached; users can be placed in a wait queue.
• Potential § 102 mapping: Strong on (i) multiple threads in a single pane (the "merged view" element of claims 1/5/8/12 and claims 3/7/10), and (ii) a sender-set maximum number of responses/sessions plus an automatic follow-up message — the "maximum number … second instant message" feature of claim 2 (and its echo in claim 11). It does not disclose the responder-controlled merge opt-out. No full-claim anticipation.

3.4 US 2007/0282956 A1 — AOL ("Displaying complex messaging threads into a single display")

• Full citation: U.S. Patent Application Publication 2007/0282956 A1, "Displaying complex messaging threads into a single display," assignee AOL LLC.
• Dates: filed 2006-06-01; published 2007-12-06. (§ 102(b) art.)
• Description: Consolidates multiple message threads into a single display, addressing the "synthesis" problem the '553 specification also cites. (I was unable to retrieve the full text — my verification search was cut off by a step limit; the description rests on the title/abstract as listed on the patent and general knowledge of the reference.)
• Potential § 102 mapping: Relevant to the "merged threaded view" element of claims 1/5/8/12 and the single-window/threaded display of claims 3/7/10. No opt-out teaching → no full-claim anticipation.

3.5 US 2010/0023586 A1 (US 9,117,211) — IBM (correlating Q&A in IM)

• Full citation: U.S. Patent Application Publication 2010/0023586 A1, "System and method for correlating questions and answers in an instant messaging environment," assignee IBM; matured as US 9,117,211 B2 on 2015-08-25.
• Dates: filed 2008-07-24; published 2010-01-28. Pre-AIA § 102(e) art (published after the '553 filing date but filed before it).
• Description (corroborated): An IM client with multiple zones/textboxes keys each answer to the specific question, so that with three or more speakers each responder's answer is shown in a correlated, per-speaker window rather than one chronological stream.
• Potential § 102 mapping: Relevant to the question/answer framing of claims 2, 6, 9, 12 and to per-responder separate displays (claim 12 / claims 3, 7, 10). No merging-opt-out → no full-claim anticipation.

3.6 US 2009/0150498 A1 — Branda (combining related messages into a composite view)

• Full citation: U.S. Patent Application Publication 2009/0150498 A1, "Identifying a plurality of related electronic messages and combining the plurality of related messages into a composite view," Steven Joseph Branda.
• Dates: filed 2007-12-07; published 2009-06-11. (§ 102(b) art — published before 2009-02-19.)
• Description: Identifies related messages and combines them into a single composite view.
• Potential § 102 mapping: Merged-view element of claims 1/5/8/12; combined-thread view of claims 3/7/10. No opt-out.

---

4. Tier 2 — Relevant to specific elements

---

5. Claim-by-claim anticipation summary

Bottom line on § 102: The cited references establish that one-to-many community IM (US 2004/0019637), multi-threaded IM with a merge function (US 7,475,110), single-pane multi-thread discussion with a response limit (US 2006/0059235), merged/composite thread displays (US 2007/0282956; US 2009/0150498), and Q/A correlation (US 2010/0023586) were all known before 2009-02-19. But the unique combination — a responder-controlled opt-out that keeps that private thread out of the shared merged view while the sender retains immediate, permission-free access to all threads — is not disclosed by any single cited reference, and therefore no claim of US 8,473,553 is anticipated under § 102 by the art cited on its face.

---

6. Caveats and residual uncertainty

1. Not a legal conclusion. These are technically-grounded provisional mappings; anticipation is finally a legal determination on the full record (including prosecution history).
2. Verification gaps. My corroborating searches for US 2007/0282956 A1 (AOL), US 2008/0028027 A1 (Jachner), and US 6,212,548 B1 (AT&T) were cut off by a step limit before returning results. Their descriptions rest on the patent's own citation listing plus general knowledge and should be re-verified against full text before being relied upon. All other Tier 1 descriptions were corroborated on the open web.
3. Foreign/non-patent art. The patent's face lists only U.S. references; the Google Patents record also shows a "Similar Documents" entry — Morgado et al., "Architecture for transparent helpdesk system with multimodal presence," 2010 — which post-dates the 2009-02-19 critical date and is therefore not prior art here. Likewise, the "Cited By" and "Families Citing this family" lists (e.g., US 9,246,857; US 10,116,599; WO 2017/099483) are forward citations and are not prior art.
4. Identifier discipline. As noted in § 0, US 8,473,552 (Microsoft IPR2016-01146) is a different patent and has been excluded; likewise the records for US 8,489,599 and the Vaporstream patents discussed in the earlier litigation section are unrelated to this number.

If you can restore search steps, the highest-value follow-ups are: (a) full-text verification of items #30, #31, #4 above; and (b) a § 103-oriented combination analysis (e.g., US 7,475,110 + US 6,993,564) directed at the responder-controlled opt-out limitation, which is where any invalidity challenge would realistically have to focus.

I'll verify the disclosures of the key cited references before building the combinations.

Let me verify the community/one-to-many and privacy references.

Obviousness Analysis — U.S. Patent No. 8,473,553 under 35 U.S.C. § 103

Note on the date discrepancy (flagged per your rules): this task header says "Current Date: April 26, 2026," whereas the operating instructions supplied with this file say "Today's date: 2026-09-29," and the previously generated sections are dated 2026-09-29. I use 2026-09-29 as the operative date (consistent with the operating rules and the prior sections) and flag the conflict rather than silently harmonizing it. Nothing in the substantive §103 analysis turns on the ~5-month difference.

Build on prior sections: the earlier sections established two things I rely on here and do not repeat: (1) the issued independent claims (1, 5, 8, 12) are directed to merging private one-on-one response threads into a shared "merged threaded view" with a responder-controlled opt-out — not to the "satisfaction message" that dominates the abstract (that feature lives only in dependent claim 2); and (2) the patent is untested — no IPR/PGR/CBM, no district-court assertion found, all 12 claims standing as issued since 2013-06-25 (see https://patents.google.com/patent/[US8473553](/patent/US8473553)/en). That posture matters for §103: there is no IPR estoppel, no PTAB-construed scope, and no secondary-considerations record. A §103 case therefore starts from a blank slate and can be built entirely from the prior art already of record in the patent's own cited-art list.

---

I. Governing law and legal framework

Because the application was filed 2009-02-19, the pre-AIA version of 35 U.S.C. § 103 applies (AIA §§ 3(n)(1) first-to-file provisions govern applications filed on or after 2013-03-16). The pre-AIA § 103(a) analysis under Graham v. John Deere Co., 383 U.S. 1 (1966), and KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), proceeds as follows:

1. Determine the scope and content of the prior art.
2. Ascertain the differences between the prior art and the claims at issue.
3. Resolve the level of ordinary skill in the pertinent art.
4. Evaluate objective evidence of nonobviousness (secondary considerations).

Under KSR, a claim is obvious where "a court must ask whether the improvement is more than the predictable use of prior art elements according to their established functions," 550 U.S. at 417, and where a "design need or market pressure" or a finite number of identified, predictable solutions exists, id. at 421. Where a combination of familiar elements yields only predictable results, "the combination is likely obvious." Id. at 416. Under In re Keller, 642 F.2d 413, 425 (CCPA 1981), the test for a combination is what the combined teachings suggest to a person of ordinary skill, not whether each reference individually contemplates the specific claimed combination.

All references below predate the 2009-02-19 priority date and qualify as prior art under at least pre-AIA §§ 102(b) and/or 102(e) (verified against each reference's publication/grant date). They are, notably, the very references the Examiner cited of record — which means prosecution history does not provide an "art not considered" hurdle, but also means the patent owner cannot claim the field was unrecognized.

---

II. Level of ordinary skill in the art (POSITA)

A POSITA as of February 2009 would hold a bachelor's degree in computer science, computer engineering, or electrical engineering (or equivalent), plus at least two years of experience designing networked client/server messaging or real-time collaboration applications, or the equivalent combination of education and experience. Such a person would be familiar with:

• Instant messaging clients and protocols in wide commercial use (IBM Lotus Sametime, AOL Instant Messenger, ICQ, MSN Messenger, Yahoo! Messenger) and their multi-window session models;
• Threaded discussion concepts from email and Usenet, and their adaptation to IM (the patent itself concedes this at the "BACKGROUND" and the Taiwan family member's discussion of newsgroups);
• Presence/privacy controls (buddy lists, block/ignore, authorization-to-receive, anonymity settings); and
• Publish/subscribe messaging as a broadcast primitive for one-to-many IM.

This is a crowded, mature art. The '553 patent's own background section confirms the field was developed: "Electronic or computerized instant messaging tools exist that allow a person … to send a question … to some or all members of a particular topic-based community at the same time."

---

III. Key claim terms and the practical scope at issue

The independent claims turn on four functional elements (all phrased as result, not algorithm — the §112(b) vulnerability noted in the prior strategic section, and repeated here only to note it is also a §103 problem because broad functional language is easier to read on the prior art):

Claim 12 adds only the question/answer framing and "initially placing each … in a separate display." Claim 2 adds the maximum number of responses + "satisfied" second message.

---

IV. The prior art of record, mapped to the claim elements

---

V. Ground 1 — Claims 1, 3–5, 7, 8, 10–12 are obvious over US 2004/0019637 A1 (SkillTap) in view of US 2006/0059235 A1 and/or US 7,475,110 B2

The primary reference alone teaches most of the claim

The SkillTap disclosure (US 2004/0019637 A1, verified at https://patents.google.com/patent/US20040019637 and https://uspto.report/patent/app/20040019637) is startlingly close. Verbatim from the record:

• Broadcast to a community (Element A): "[T]he present invention (herein called 'SkillTap') utilizes Pub/Sub Applications to publish an Instant Message (IM) from a requester to subscribers of a Pub/Sub channel (listeners)."
• Private one-on-one threads (Element B): "[T]he requester receives IM's from each responder in separate windows and elects one responder to converse with at a time." Each return message "opens an IM window on Brian's computer which initiates the IM conversation between Brian and Mike."
• Merging the private threads into a shared view (Element C): "In a preferred embodiment, the SkillTap application allows Brian to use his mouse to drag a conversation window into another conversation window. The resulting new combination window displays messages from both listeners in a single window." And the group-view embodiment: "[T]he return message opens a chat room … The chat room enables multiple listeners to participate in the conversation, it allows multiple listeners to view the conversation between Brian and Mike or optionally only provides Brian with a single instance of an IM window … wherein each listener only sees conversation directed to him."
• De-merging / pulling a thread out (prologue to Element D): "Similarly, Brian uses his mouse to drag a user's message out of the window which creates a new conversation window for that conversation and optionally eliminates the dragged user from the original window."
• Availability without further permission (Element E): Responses "open normal IM windows at the requester's terminal"; the assembly/disassembly is a direct-manipulation UI action with no gating step.

The multi-threaded-IM references supply the "threaded" character and the "merge" control

The '553 claims recite a "merged threaded view," and the specification describes it as "thread" aggregation (blocks 164–176). The independent claims' word "threaded" is supplied by art of record:

• US 7,475,110 B2 discloses segregated conversation threads (thread IDs appended to message headers) and a "merge thread button 708" that "merge[s] the threaded display of the messaging session into a chronological conversational format" (see https://patents.google.com/patent/[US7725538B2](/patent/US7725538B2)/en, which quotes the '110 disclosure). Merging discrete threads into one view is thus expressly known.
• US 2006/0059235 A1 discloses "multiple threads, or topics, … managed and displayed within a single instant messaging session," each thread's messages grouped in its own display area, with expand/collapse — i.e., the claimed separate display → threaded view transition.
• US 2007/0282956 A1 (AOL) discloses aggregating a root message and literally dozens of child reply messages into "a single display" — the claimed "merged … view."

Motivation to combine (why a POSITA would have done this)

1. Same field, same problem, same solution shape. All four primary references are in computerized IM/collaborative messaging; all address the identical problem the '553 background recites — a sender overwhelmed by many simultaneous responses and difficulty "synthesizing the response information … if the content of the responses is managed in different windows or views." The '553 patent's stated problem is not new; it is exactly the problem SkillTap, the multi-threaded-pane references, and the AOL thread-aggregation reference each set out to solve.
2. The references expressly invite the combination. US 2007/0282956 A1's background states that its techniques "extend to other forms of messaging … such as … instant messaging." US 7,475,110's "merge thread" control is designed to be applied to any threaded IM display. SkillTap itself says "Many other window variations would be useful and become obvious in light of the present invention." That is a teaching-away-free, express-suggestion record.
3. Predictable, mechanical result (KSR). Combining (a) a known community broadcast/private-response model with (b) known per-thread display objects and (c) a known "merge" UI control is the "predictable use of prior art elements according to their established functions." KSR, 550 U.S. at 417. Nothing in the combination changes the operation of any element.
4. Finite, identified solutions. The art had already identified the finite menu of ways to reduce response-management burden: queue/throttle (US 2006/0059235; SkillTap throttles), aggregate into one window (US 2007/0282956; SkillTap drag-merge), or thread the display (US 7,475,110; US 2008/0028027). The claims select from that finite menu — the classic KSR "obvious to try" posture.

Element-by-element summary for claim 1

Conclusion (Ground 1): claims 1, 3, 4, 5, 7, 8, 10, 11, and 12 are obvious. Claim 4 (excluded thread viewable by sender + the opting-out responder only; merged view by all) is met by SkillTap's alternative "chat room" vs. "only sees conversation directed to him" disclosure.

---

VI. Ground 2 — Claim 2 is obvious over Ground 1 further in view of US 2006/0059235 A1 (and SkillTap's own throttle)

Claim 2 recites (i) question/answer form, (ii) separate initial displays, (iii) the first person setting a maximum number of responses, and (iv) sending a second IM indicating satisfaction after the maximum is reached.

• (ii) separate displays: SkillTap — "separate windows"; also US 2006/0059235's per-thread windows.
• (iii) maximum number of responses: SkillTap discloses "message throttles … to limit number of listeners engaging the requester" and "Responses to the requester are limited by any of a predetermined number of messages, a predetermined time window, a predetermined algorithm of priority … or message sender's credentials." That is the claimed sender-set maximum, almost verbatim in substance. US 2006/0059235 A1 independently discloses a user-entered "maximum number of active instant messaging sessions" together with an automatically sent message to the late requestor ("I'm busy right now, want to join the queue?").
• (iv) the "satisfied" second message: The '553 step 156/160 concept — notifying the community that the question is answered / no more responses wanted — is the functional equivalent of the SkillTap acknowledgment/close-the-session flow and the US 2006/0059235 automatic "busy" notice returned to over-limit requesters. Framing the notice as "I am satisfied with at least one response" is a label on a result already achieved; the notice content is a non-technical choice that does not patentably distinguish the claim. KSR at 418–422 (predictable variation; design choice).
• (i) question/answer framing: explicitly disclosed by US 2010/0023586 A1 ("correlating questions and answers in an instant messaging environment," priority 2008-07-24 — §102(e) art) and US 2008/0133671 A1 ("Instant answering"), and inherent in the SkillTap "Ask …" workflow.

Conclusion (Ground 2): claim 2 is obvious. Claims 6 and 9 (which add only the question/answer form) are likewise obvious in view of the same art.

---

VII. Ground 3 — The responder-controlled opt-out (Element D) is obvious over Ground 1 in view of the privacy/authorization art of record

The only limitation that SkillTap does not squarely disclose from the responder's side is Element D: "preventing an identified private thread from being merged … responsive to a particular one of the plurality of other persons selecting to prevent the … thread from being merged." SkillTap's drag-out is requester-driven. But the specification (block 172) gives the reason for the limitation in plain terms: "due to privacy concerns, a responder may choose to prevent its private one-on-one conversation thread with User A from being merged." The motivation is therefore express in the patent itself, and the art of record supplies the mechanism:

• US 6,993,564 B2 (AT&T) — "Method of authorizing receipt of instant messages by a recipient user." The recipient (i.e., the responder) controls the communication path — the exact recipient-side authorization architecture the claim requires. Substituting a "do not merge my thread" preference for the "do not deliver / do not accept" preference of the '564 patent is a predictable reapplication of a known recipient-authorization control.
• US 2004/0019637 A1 itself teaches responder-set privacy preferences: the SkillTap setup lets a subscriber choose "whether the user wants to be anonymous in transactions" and provides "a warning if he is about to break anonymity." That is a responder-controlled election governing how that responder's contribution is exposed to others — the same genus as an opt-out from publish/merge.
• US 2005/0065632 A1 / US 7,325,034 B2 (IBM) — "scalable peer-to-peer inquiries in a network of untrusted parties" — supplies the general privacy-in-community-messaging theme.
• Background/common knowledge: recipient-controlled block/ignore/authorization and presence-privacy controls were ubiquitous in AIM/ICQ/Sametime well before 2009 (a point the prior sections' sources corroborate, e.g. the Q-Link "option of responding to or ignoring the messages," https://patacts.uspto.gov/ptacts/public-informations/petitions/[1491254](/patent/1491254)/...).

Motivation to combine: the patent's own specification states the reason (privacy). The combination of a merge feature (US 7,475,110; SkillTap) with a recipient-controlled block/opt-out (US 6,993,564; SkillTap anonymity) merely gives the responder the ability to keep in the private state the exact content the merge feature would otherwise promote. There is no change in the principle of operation of any element; the result — a thread that stays private — is exactly what the opt-out control is designed to achieve. KSR at 417; In re Keller at 425.

Conclusion (Ground 3): Element D is obvious over the combination; claims 1, 5, 8, and 12 are therefore obvious in full.

---

VIII. Ground 4 (alternative) — Whole-claim anticipation-adjacent framing

Although the better theory is obviousness (because no single reference is shown in a single embodiment to practice all of A–E), the reviewer should note that US 2004/0019637 A1 comes very close to anticipating claim 1 as a combination of its disclosed embodiments, and would be the natural §102(a)/(b)/(e) reference to plead as a fallback. Its "chat room" embodiment (Element C, group-visible) together with its separate-private-window embodiment (Element B) and its throttle (claim 2) are all disclosed in the same specification. A §102 challenge built on a single reference's alternative embodiments is legally awkward (different embodiments generally may not be combined for anticipation), which is precisely why the §103 framing of Grounds 1–3 is the correct vehicle — and why the patent owner would have to argue, without a PTAB record to support it, that the combined teachings somehow do not "suggest" the claim.

---

IX. Objective evidence of nonobviousness (secondary considerations)

There is no known objective evidence of nonobviousness. Specifically:

• No unexpected results are disclosed or claimed; the specification touts only the intended benefit ("allow the sender … to review … the history," "reduce the overlap of work"), which is the stated purpose of the prior art and therefore entitled to no weight absent demonstrated superiority over the closest art.
• No commercial success, licensing, copying, or industry praise nexus is available: the patent is a division of an IBM portfolio later assigned to Snap, with no litigation and no PTAB record (per the prior sections), so there is no adjudicated evidence of praise or copying.
• No long-felt unmet need is supported: the field solved the same problem contemporaneously (SkillTap 2002; multi-threaded IM 2004–2008), which cuts against a long-felt-need narrative.

If the patent owner asserts secondary considerations, the nexus burden is theirs, and the crowded, contemporaneous art is a strong factual counter.

---

X. Anticipated rebuttals and how they fare

---

XI. Bottom line and confidence

Conclusion. Every independent claim (1, 5, 8, 12) and every dependent claim (2, 3, 4, 6, 7, 9, 10, 11) of US 8,473,553 is vulnerable to a §103 obviousness attack built entirely from the patent's own cited art. The strongest, cleanest primary reference is US 2004/0019637 A1 (IBM SkillTap), which alone discloses the community broadcast, the separate private response windows, the merging of those windows into a combined/group view, and the response throttle. US 2006/0059235 A1, US 7,475,110 B2, US 2007/0282956 A1, and US 2008/0028027 A1 supply the "threaded/merged" vocabulary and UI controls; US 6,993,564 B2 supplies the responder-controlled authorization that completes Element D; and US 2010/0023586 A1 / US 2008/0133671 A1 supply the question/answer framing for claims 2, 6, and 9.

Why this is a complete theory, not just a combination of gaps: the motivation is supplied three ways — (a) the references are in the same field addressing the same problem; (b) several references expressly suggest extending their techniques to IM and to "other window variations"; and (c) the patent's own specification states the motivation for the opt-out ("due to privacy concerns"). That satisfies KSR's "articulated reasoning with rational underpinning" and In re Keller's "combined teachings" test.

Confidence: moderate-to-high on the analysis; moderate on the factual completeness of each reference. I verified the key disclosures of US 2004/0019637 A1, US 2006/0059235 A1, US 7,475,110 B2, US 2007/0282956 A1, and US 2008/0028027 A1 against Google Patents / USPTO.report / FreePatentsOnline (URLs inline above). I did not independently verify the full text of US 6,993,564 B2 (my verification searches were truncated by a step limit), US 6,212,548 B1, US 7,328,242 B1, US 2010/0023586 A1, or US 2008/0133671 A1 — those mappings rest on their titles/abstracts in the '553 cited-art list and should be confirmed with full-text pulls before being relied on in a petition or invalidity contention.

Caveats I will not paper over: (1) the task/operating-rule date discrepancy noted above; (2) the pre-AIA vs. AIA question — I applied pre-AIA §103, which is correct for a 2009 filing but should be stated expressly in any formal paper; and (3) there is no adjudicated record for this patent (per the prior sections), so this is a prima facie obviousness assessment, not a prediction of how a tribunal would construe the functional language or weigh any secondary considerations the owner may later adduce.