US 7706782

I'll search for this specific patent and check for any 2026 litigation activity.

Now let me check for any litigation activity involving this patent.

US Patent 7,706,782 — Summary

Search scope note: I searched for the literal identifier "7706782" (and "US7706782B1") against publicly accessible patent databases (Google Patents, FreePatentsOnline, Justia, Unified Patents portal) and against public web/legal-news sources for 2026 Federal Circuit activity. I do not have direct PACER, USPTO PatentCenter, or CAFC docket-query access from this session, so the litigation finding below is based on open-web indexing rather than an authoritative docket pull.

Bibliographic data (consistent across sources)

Assignment chain (as recorded): Macromedia, Inc. (recorded 2004-06-28) → Adobe Systems Incorporated (recorded 2006-01-19, effective 2005-12-07) → Adobe Inc. (change of name, effective 2018-10-08, recorded 2019-04-08).

Abstract (as printed): "A system and method is described for providing data to a mobile information system. A broadcast server receives information preferences from a plurality of subscribers to the mobile information system. The broadcast server aggregates these information preferences and transmits the aggregated information preferences to at least one data source providers. The data source providers then assemble data for the mobile information system using the aggregated information preferences."

Independent claims — plain-language overview

The patent has 26 claims, with four independent claims (1, 9, 17, 25); claims 2–8 depend from 1, 10–16 from 9, 18–24 from 17, and 26 from 25.

Claim 1 — Method (aggregation upstream of the data source). Receive information preferences from multiple subscribers to a mobile information system, where each subscriber's preferences specify at least one type of dynamically changing information available from the same data source provider. Aggregate those preferences, where at least two of the aggregated preferences correspond to different data of that same data source provider. Transmit the aggregated preferences to that same data source provider. Then assemble the data for the mobile information system using the aggregated preferences. In short: many users' asks are pooled and pushed to the content source, rather than each device pulling its own feed.

Claim 9 — System (means-plus-function). The same concept expressed as a "means for" system for a mobile rich media information system: means for gathering preferences from subscribers; means for assembling two or more preferences that correspond to different data of a same data source provider into an aggregate preference; means for transmitting that aggregate preference to the data source provider; and means for compiling data for the mobile rich media system using the aggregated information preferences. (Because it is drafted in means-plus-function form, the scope is presumptively limited under 35 U.S.C. § 112(f) to the corresponding structures disclosed in the specification — e.g., the enhanced broadcast server 401 and data providers 402-1–402-N — and equivalents.)

Claim 17 — Computer program product. A CRM carrying program logic: code for receiving preferences from subscribers, each preference identifying a subset of dynamically changing information available for subscription through at least one information channel; code for assembling them into an aggregate preference where at least two of the assembled preferences correspond to different data of a same information source provider; code for transmitting the aggregate preference to that source provider; and code for compiling information using the aggregate preference.

Claim 25 — Method (server-centric "superset/subset" framing). Receive at an enhanced broadcast server preferences from subscribers specifying, for each, a subset of information available from at least one data provider with which the server is communicatively coupled and of interest to that subscriber. The server aggregates the preferences for different information available from one of the data providers to form a superset of information of interest to the group. The server sends a request for that superset to that data provider, receives the superset back, then determines the corresponding subsets of the received superset that are of interest to each individual subscriber based on that subscriber's preferences, and sends those determined subsets to each subscriber. This is the clearest statement of the patent's two-stage architecture: aggregate demand upstream, disaggregate content downstream.

Claim 26 — Dependent on 25. Adds sending to a subscriber an aggregate of received information from different data providers that are of interest to that subscriber (i.e., cross-source channel assembly at the server).

Representative dependent-claim themes: channel-based separation of preferences (claims 2, 10, 18); availability/connection checks to only send to currently connected subscribers (5, 13, 21); per-subscriber bandwidth-limit gating (6, 14, 22); and XML / "data-descriptive meta-language" documents obtained by polling a formatted document, polling and XSLT-transforming an unformatted document, library-resource push, or a dedicated data development server (7–8, 15–16, 23–24).

Litigation / CAFC 2026 check

I found no evidence of any Federal Circuit appeal, district court action, ITU/ITC proceeding, or PTAB (IPR/PGR) challenge involving U.S. Patent 7,706,782 in the 2026 timeframe, or at any time. Specifically:

• No 2026 CAFC opinion, Rule 36 affirmance, or docket entry matching this patent number surfaced.
• No PTAB petition number referencing 7,706,782 surfaced.
• Its forward-citation list is dominated by Adobe's own later mobile-media continuations and unrelated third-party patents (e.g., a Sybase 365 content-distribution publication), which is consistent with a patent that was never asserted.

Important caution — do not conflate similar numbers. Searches for the literal string surfaced unrelated matters whose identifiers differ: 7,707,624 (RPost e-signature suit against Adobe/EchoSign), 7,258,178, and 7,177,798 (Rensselaer v. Amazon "Alexa"). None of these is US 7,706,782. I have not substituted any of them.

Confidence level: High on bibliographic data and claim content (the full patent text is available and internally consistent across Google Patents, FPO, Justia, and the Unified Patents portal). Moderate on the absence of litigation — this reflects the limits of open-web indexing, not a docket-level clearance search. To confirm, a PACER docket search (all district courts, party = Adobe Inc./Adobe Systems) and a USPTO Patent Trial and Appeal Board proceeding search by patent number would be required.

Practitioner-oriented observations

1. Term is over. The patent is marked expired with an adjusted expiration of 2025-02-03, so it cannot be asserted for prospective infringement. Its main continuing relevance is defensive/prior-art value and as the parent of US 8,064,890 B1.
2. Claim 1 has an unusual narrowing hook relative to generic "personalized content" art: the "at least two of said aggregated information preferences correspond to different data of said same data source provider" limitation, plus the "dynamically changing information" requirement. That combination (multi-user aggregation across distinct data items from one source, for changing data) is the point of distinction over broadcast/filter systems like POINTCAST discussed in the background.
3. Claim 25/26 read on a modern content-delivery architecture (edge/aggregation server that requests a superset from an origin and then fans out per-user subsets) — which is why this family still shows up in forward-citation landscapes despite never being litigated.

Sources: https://patents.google.com/patent/US7706782B1/en ; https://www.freepatentsonline.com/7706782.html ; https://patents.justia.com/patent/7706782 ; https://portal.unifiedpatents.com/patents/patent/US-7706782-B1

I'll research litigation involving US patent 7706782 (the "System and method for developing information for a wireless information system" patent, originally Macromedia/Adobe Systems, now Adobe Inc.).

The initial results returned the unrelated "5,207,678"/"'678 patent" (DePuy v. Medtronic spinal screws) — that is a different patent and must not be conflated with US 7,706,782. Let me search more precisely.

Let me run more targeted queries, including the Unified Patents patent page and any Adobe assertion of this patent.

Summary of Findings

I found no litigation involving US Patent 7,706,782.

After searching patent-litigation sources (Unified Patents portal patent page for US-7706782-B1, Google Patents' full record for US7706782B1, CourtListener/RECAP, Docket Alarm, Justia Dockets, and general web searches targeting the number both with and without commas), I found no district-court case, ITC investigation, PTAB proceeding, or Federal Circuit appeal in which US 7,706,782 was asserted, challenged, or otherwise at issue. The authoritative Google Patents record supplied for this patent likewise contains no "Litigation" section — only "Cited By" references (which are later patents citing it as prior art, not lawsuits).

Negative results are important here — several near-miss identifiers exist

Per the instruction to interpret identifiers literally and not auto-correct, note these distinct items that appeared in search results and that must not be attributed to US 7,706,782:

Additional context on the patent itself (from the authoritative record)

• Patent: US 7,706,782 B1, "System and method for developing information for a wireless information system"; App. No. 10/791,299; filed/priority 2004-03-01; granted 2010-04-27.
• Assignee chain: Macromedia, Inc. → Adobe Systems Incorporated → Adobe Inc.
• Legal status: Expired – Lifetime; adjusted expiration 2025-02-03 (per the record consulted 2026-09-21). With the patent term now lapsed, new infringement suits are effectively foreclosed (past-damages windows also closed with the § 286 six-year lookback long expired).
• Continuation: US 8,064,890 B1 (from App. No. 12/757,839, filed 2010-04-09) is a continuation in the same family; the Google Patents record shows no litigation for it either.

Caveat on confidence

My searches did not include a direct, verified pull from the Unified Patents litigation case list (portal.unifiedpatents.com/litigation/caselist) — that page did not return content in the results — nor a paid PACER docket-by-patent query. It is therefore possible that a very obscure, quickly-dismissed, or pre-2010 case exists that is not indexed in the free sources I reached. However, across all free litigation databases and the patent's own prosecution/citation records, there is no evidence of any case involving US 7,706,782, and the patent's expired status makes unknown future litigation implausible.

Bottom line: No known litigation involving US Patent 7,706,782. If you need a definitive, certified negative, I would recommend running a paid Darts-ip, Lex Machina, or LexisNexis Patent Litigation query keyed to patent number 7706782 (and its family member 8064890), which would capture any unindexed early filings.

Proceedings overview

Total AIA trial proceedings on US 7,706,782: zero. There is nothing to break down — no IPRs, no PGRs, no CBM reviews — so the counts are: active 0 / claims invalidated 0 / claims sustained 0 / settled 0 / institution denied 0. The canonical source (the USPTO Open Data Portal "PTAB proceedings on file" block) returns no AIA trial proceedings for this patent as of the most recent ingest, and my independent web searches surfaced no petition, institution decision, final written decision, or Board appeal tied to this patent number. Bottom line for a defendant: there is no PTAB record to lean on. You cannot point to canceled claims, and you cannot invoke anyone else's § 315(e)(2) estoppel. But you also do not need to — the patent is marked Expired – Lifetime, adjusted expiration 2025-02-03, so an IPR would be an academic exercise and a district-court assertion of these claims is, under the record consulted 2026-09-21, foreclosed.

Proceedings

None. There are no AIA trial proceedings on file for US 7,706,782.

I searched petition-level sources (PTAB E2E / PTACTS petition documents, Docket Alarm PTAB, the Google Patents record's absence of any "PTAB" section) and general web sources for the literal strings 7706782, US7706782, and US-7706782-B1 combined with IPR, PGR, CBM, petition, and institution. Searches also cleared the application number 10/791,299 and the family continuation US 8,064,890 B1. No proceeding numbers were found, and per your instructions I have not invented any to populate the template.

Because the required per-proceeding structure (panel, grounds, institution reasoning, claim-level FWD disposition, appeal) presupposes a record, none of those fields can be filled without fabricating them.

Near-miss identifiers explicitly excluded

Consistent with the earlier litigation section's caution, these are different matters that surfaced and must not be attributed to US 7,706,782:

Strategic summary

Claim status of US 7,706,782: all 26 claims are UNTESTED at the PTAB. No claim has been canceled, disclaimed, or amended through an AIA trial, and no certificate issuing from such a trial exists. All four independent claims remain as issued — claim 1 (aggregation method with the "at least two … different data of said same data source provider" hook), claim 9 (means-plus-function system for a mobile rich media information system), claim 17 (computer program product), and claim 25 (enhanced-broadcast-server superset/subset method) — together with dependent claims 2–8, 10–16, 18–24, and 26. The only occurrence that has narrowed anything is the passage of time: the record reflects an adjusted expiration of 2025-02-03, so the enforceable term has lapsed. From a pure defensive standpoint, the patent's claims are "live" only in the sense that they remain citeable as prior art and remain a validity reference point, not as a basis for prospective liability.

Estoppel landscape: none of the § 315(e) machinery is engaged. Section 315(e)(1) estoppel (patent owner side, barring a new challenge to a canceled claim) and § 315(e)(2) estoppel (petitioner side, barring in civil actions or ITC proceedings any ground raised or that reasonably could have been raised) both attach only after a final written decision under § 318(a). There has never been one here, so no party — and no privy — is estopped as to any claim of this patent by any PTAB record. Practically, that means if a defendant today wanted to run an invalidity theory against 7,706,782, the field of prior art is completely open: no ground is unavailable, no reference is off the table, and there is no risk of an estoppel-based motion to strike. The corollary is equally true and worth flagging to a client: because there is no FWD, there is also no Helpful canceled claim to point at, and no estoppel protecting the patent owner either.

Pattern signals: none from this patent; the signals run the other way for Adobe. This patent has never attracted a petitioner, which — as you note — is itself a signal: well-asserted, commercially significant patents eventually draw IPRs, and the total absence of petitions across a 21-year life is consistent with the earlier finding that the patent was never asserted against anyone. What the searches did reveal is the mirror image: Adobe is a prolific IPR petitioner in its own defense (multiple petitions against RAH Color Technologies and William Grecia in 2018–2019, a petition against Express Mobile in 2021), always on the challenger side. There is no defensive aggregator (Unified Patents or similar) anywhere in this patent's chain, and no third-party petitioner traffic whatsoever. The related family members from the same 2004-03-01 filing — 10/791,298 → US 7,822,428 B1 ("Mobile rich media information system") and 10/791,311 ("Bandwidth management system") — likewise produced no AIA proceedings in the ad-hoc searches I ran (limited check on 7,822,428; I did not complete a check on the patent issuing from 10/791,311 and do not assert a result for it). I flag that as a weak cross-family observation, not a canonical finding — the ODP block covers only 7,706,782, and I have not done the equivalent API pull on the siblings.

Recommended next steps

• State the negative plainly on the record. For this patent there is nothing to "win" at the PTAB and nothing to cite. If you are drafting a validity opinion or an invalidity contentions section, the correct statement is: no AIA trial proceedings exist for US 7,706,782 — with the caveat that verification should be a direct PTAB E2E / PTAB API query by patent number (https://ptacts.uspto.gov/ptacts/) rather than a web search.
• Do not plan around an FWD that does not exist. There is no final written decision to link or quote; any brief that implies otherwise would be sanction-exposed. The only documents of record are the prosecution history and the patent itself.
• An IPR is legally possible but strategically pointless. Expiration does not itself bar institution, and the Board has instituted on expired patents (where claim construction shifts to the Phillips framework). But with the term ended per the record's adjusted expiration of 2025-02-03, there is no injunction or ongoing-royalty exposure to eliminate, and past damages under § 286 are long foreclosed. A defendant's resources are better spent confirming the expiration math and the maintenance-fee history than on a petition.
• If you nevertheless need a belt-and-suspenders negative for a diligence file, run the paid queries: Darts-ip / Lex Machina / LexisNexis Patent Litigation keyed to 7706782 and 8064890 (the continuation, US 8,064,890 B1, filed 2010-04-09 from App. No. 12/757,839). Free-source coverage for pre-2010 filings and quickly-terminated proceedings is imperfect, but the expired status makes an unknown future proceeding implausible.
• Watch for the number-confusion trap. If opposing counsel or a demand letter cites "the '678 patent," verify the full seven digits before responding — the Raytheon, DePuy, and Adobe/Grecia matters above all surfaced on similar strings and are unrelated.

Sources consulted: USPTO PTAB E2E / PTACTS petition portal — https://ptacts.uspto.gov/ptacts/ ; PTAB decisions — https://www.uspto.gov/patents/ptab/decisions ; Google Patents record for US7706782B1 — https://patents.google.com/patent/US7706782B1/en ; Docket Alarm PTAB dockets — https://www.docketalarm.com/ ; Federal Circuit nonprecedential disposition in No. 2017-1554 — https://cases.justia.com/federal/appellate-courts/cafc/17-1554/17-1554-2018-04-02.pdf ; CourtListener — https://www.courtlistener.com/ . The canonical "PTAB proceedings on file" statement in this prompt derives from the USPTO Open Data Portal and is controlling over the web-search results above.

I'll research the assignment record for US 7,706,782, cross-referencing the USPTO Assignment Center data already embedded in the authoritative Google Patents record.

Let me try to pull the USPTO Assignment Center records and correspondent data directly.

Let me check the related family applications and any correspondent-of-record data I can verify.

Ownership reconstruction — US 7,706,782 B1

Source-access caveat (carry-over from the earlier sections): I do not have a live, authenticated session against assignmentcenter.uspto.gov / assignment.uspto.gov from this run. The reel/frame values below are drawn verbatim from the authoritative Google Patents legal-events block supplied for this patent, which mirrors the same underlying USPTO assignment records. The correspondent-of-record field is not exposed in that block, and my follow-up searches did not surface it. Accordingly, I have marked correspondent data as not retrievable rather than reconstructing it. Everything else below is grounded in recorded reels/frames.

Inventors

Pattern assessment — no red flag:

• All seven inventors appear as assignors on a single recorded assignment to Macromedia, executed 2004-06-07 through 2004-06-15 and recorded 2004-06-28 — i.e., roughly three months after the 2004-03-01 filing. That timing is the ordinary "assignment recorded after the application is filed" sequence, not an unusual event.
• The record shows no evidence that any inventor departed the original assignee within 12 months of filing, and no inventor is named as an assignor on any subsequent link in the chain. There is no inventor-to-LLC conveyance, which is the classic fire-sale precursor.
• The seven-inventor group stayed with the asset through the Macromedia→Adobe transfer rather than each retaining or separately monetizing a share.

Original assignee

Two distinct answers, and they should not be conflated:

• Assignee at filing (application 10/791,299, 2004-03-01): Macromedia, Inc. (California). Macromedia was an operating software company — its primary line of business was authoring and rich-media/Web development tools (Flash, Shockwave, Dreamweaver, Director, ColdFusion). It shipped commercial products, and the claimed subject matter (aggregating subscriber preferences upstream of a data source and fanning out subscriber-specific feeds to mobile devices) sits squarely in the mobile rich-media distribution stack that Macromedia was building in 2003–2004 — consistent with the concurrently filed sibling applications cited on the face: Ser. No. 10/791,298 ("Mobile rich media information system") and Ser. No. 10/791,311 ("Bandwidth management system").
• Assignee named on the issued patent (2010-04-27): Adobe Systems Incorporated. Adobe is also an operating company and remains one today; it does ship products in this space (mobile/rich-media authoring and delivery tooling, Flash-adjacent runtime and publishing infrastructure). Current status: operating, publicly traded, renamed Adobe Inc. (change of name effective 2018-10-08, recorded 2019-04-08).

Macromedia's status: acquired — absorbed by Adobe by merger, closed in December 2005 (the assignment record carries an effective date of 2005-12-07). It was not a bankruptcy, dissolution, or fire-sale.

Assignment timeline

Three recorded events bearing on ownership, plus fee/status events. No third-party conveyances exist.

• 2004-06-07 to 2004-06-15 (executed) / recorded 2004-06-28 — Reel 015507/0806

  • Conveyance: Assignment (ASSIGNMENT OF ASSIGNORS' INTEREST)
  • Assignor: Hosmer, Basil C.; Connolly, Brian P.; Chatterjee, Saurav; MacDonnell, Samuel J.; Meyrowitz, Norman K.; Morris, James T.; Sellier, Laurent E. (all seven inventors)
  • Assignee: Macromedia, Inc., California
  • Correspondent: not retrievable from the available record. No recurrence to flag.
  • Context: Initial employment/work-for-hire assignment of the application to the operating company that filed it.

• 2005-12-07 (executed) / recorded 2006-01-19 — Reel 017034/0263

  • Conveyance: Assignment (ASSIGNMENT OF ASSIGNORS' INTEREST; ASSIGNOR: MACROMEDIA, INC.)
  • Assignor: Macromedia, Inc.
  • Assignee: Adobe Systems Incorporated, California
  • Correspondent: not retrievable from the available record. No recurrence to flag.
  • Context: Internal corporate reorg / merger integration — portfolio transfer following Adobe's acquisition of Macromedia; executed on the merger closing date, recorded ~6 weeks later. Not a sale to a third party.

• 2018-10-08 (executed) / recorded 2019-04-08 — Reel 048867/0882

  • Conveyance: Change of Name (ASSIGNOR: ADOBE SYSTEMS INCORPORATED)
  • Assignor: Adobe Systems Incorporated
  • Assignee: Adobe Inc., California
  • Correspondent: not retrievable from the available record. No recurrence to flag.
  • Context: Change of name only — no change in beneficial ownership.

Status/fee events (not assignments): STCF patent-grant notice 2010-04-07; 4th-year fee 2013-09-25; FEPP 2014-12-03; 8th-year fee 2017-10-12; 12th-year fee 2021-10-27. Adjusted expiration 2025-02-03; status Expired – Lifetime.

No post-issuance assignment to any entity outside the Adobe corporate family exists on the record. There is no LLC, no trust, no security interest, and no release/correction filing.

Timeline diagram

timeline
    title Ownership of US 7706782
    2004 : Filed by seven inventors
         : Assigned to Macromedia Inc reel 015507 0806
    2005 : Adobe acquires Macromedia
    2006 : Adobe assignment recorded reel 017034 0263
    2010 : Patent issues
    2019 : Name change recorded reel 048867 0882
    2025 : Patent term expires

NPE / troll-pattern signals

Verdict

Defensive / non-asserting.

Justification: the entire recorded chain is inventors → Macromedia, Inc. (reel 015507/0806, executed 2004-06-07–06-15, recorded 2004-06-28) → Adobe Systems Incorporated (reel 017034/0263, effective 2005-12-07, recorded 2006-01-19) → Adobe Inc. (reel 048867/0882, effective 2018-10-08, recorded 2019-04-08) — three events, all intra-corporate, with no transfer to any third party, LLC, or asserter at any point, and accordingly zero of the eight NPE signals present (one — repeat correspondent — is merely unverifiable for lack of the correspondent field, not affirmative). The patent expired 2025-02-03, and per the earlier litigation section it was never asserted; it is therefore non-asserting by fact, not by the usual aggregator mechanism.

Explicit deviation from the label's parenthetical: the chosen category is normally defined as "chain terminates at a defensive aggregator." That is not what happened here — no defensive aggregator is involved. I selected this label because among the five options it is the only one that accurately describes the outcome (a non-asserting patent ending in operating-company ownership); the alternative "Insufficient data" would understate what is actually a complete and unambiguous record.

Two open items to close out the record properly:

1. Correspondent-of-record for each reel/frame — the one field that could not be retrieved here. Verify at USPTO Assignment Center (mirrored at assignment.uspto.gov) by searching patent number 7706782 and opening each of reels 015507/0806, 017034/0263, and 048867/0882. Absence of a repeat correspondent is expected given the chain is intra-corporate, but it should be confirmed rather than assumed.
2. Family member reel data — the continuation US 8,064,890 B1 (App. No. 12/757,839, filed 2010-04-09) sits in the same family and should be checked for any assignment not mirrored on the parent (per the earlier sections, none is indicated, and it is likewise expired).

Verdict confidence: High that no NPE pattern exists — the chain contains no third-party transferee at all, which makes NPE attribution structurally impossible. Moderate-to-high on completeness of the reel list, contingent on a direct Assignment Center pull to confirm no fourth, un-indexed recording exists.

I'll ground this analysis in authoritative records for the patent and its cited references. Let me run targeted searches.

Let me characterize the remaining examiner-cited references precisely.

Prior-Art Analysis — US 7,706,782 B1

Patent analysed: US 7,706,782 B1, "System and method for developing information for a wireless information system," App. No. 10/791,299, filed/priority 2004-03-01, granted 2010-04-27 (Hosmer et al.; Macromedia → Adobe).

Method note (read first). The identifier used throughout is the literal 7706782 / US7706782B1. Every reference below is taken from the citation table printed on the face of the record supplied (59 patent citations; 12 non-patent citations), verified against Google Patents / FPO / Justia / Unified Patents where possible. I confirmed the content of four references directly this session (Nanja, Bowers, Ameritrade, and the IBM multicast application). For the remaining 55 patent citations I have the bibliographic face data (number, assignee, priority date, publication date, title) but not an independent full-text read; their descriptions are drawn from the record's titles/assignees and are flagged as such. I did not have access to the prosecution file history (IDS/PTO-892, examiner's rejections) or PTAB records, so the § 102 mapping below is my independent analysis of the reference disclosures against the issued claims — not a reconstruction of what the examiner actually applied.

1. The claim set being mapped against

Dependent-theme map (used in the tables): channels = 2/3, 10/11, 18/19; connection check = 5/13/21; bandwidth gating = 6/14/22; subscriber-specific streams = 4/12/20; XML / data-descriptive meta-language = 7/15/23; acquisition by polling-formatted / polling+XSLT / library-push / dedicated dev server = 8/16/24.

2. Tier 1 — references with genuine anticipatory potential

These are the only citations in the list that approach the architecture of the independent claims. Note that all four were flagged as examiner-cited in the record (the * in the Google Patents citation table).

2.1 US 2002/0107830 A1 (Nanja, Murthi) — examiner-cited

• Citation: US 2002/0107830 A1, "Aggregating web data on clients and distributing the aggregated data to wireless handheld device."
• Dates: priority/filed 2001-02-07; published 2002-08-08.
• Description (verified this session): A "web data aggregator application" 207 runs on a user's system 103 (desktop/hub) and interacts with web servers 105 via HTTP; CGI scripts 211 produce XML; XSL stylesheets transform the XML into aggregated HTML/XHTML content 210; a "data synchronizer" 208 pushes the aggregated content to a wireless handheld 101. Vendor APIs may be used instead of HTML scraping; data gathered includes weather, stock quotes, news.
• § 102 assessment — the closest reference on the acquisition limitations; weak on the aggregation limitations.
  • Potentially reads on claims 7, 15, 23 (data document from a "data-descriptive meta-language" — XML) and on the XSL-transform branch of claims 8, 16, 24 ("polling a data server containing an unformatted data document, wherein a data style layout transform is used to transform said unformatted data document into a formatted data document").
  • Does not anticipate claims 1/9/17/25: Nanja aggregates content, not preferences, and the aggregator sits on the end-user's own machine, not at a service-provider broadcast server serving plural subscribers. Its plural units are one user's devices. → More properly a § 103 reference against the independent claims when combined with a server-side aggregator (e.g., Bowers or Ameritrade).
• Confidence: High on content; moderate on claim mapping (claim 8's "polling … Web site" language tracks Nanja's HTTP/API retrieval very closely).

2.2 US 2003/0005455 A1 (Bowers, J. Rob) — examiner-cited

• Citation: US 2003/0005455 A1, "Aggregation of streaming media to improve network performance." (Abandoned application.)
• Dates: filed 2001-06-29; published 2003-01-02.
• Description (verified this session): An aggregation module receives requests for streaming media from a plurality of receivers, creates a single upstream connection via a proxy module to retrieve a single copy of the media, buffers/caches it, and then delivers it as receiver-specific streams or a multicast stream to the requesting receivers. Claim 1 of that application recites, in substance: receive requests at an aggregation module from each of a plurality of receivers → create a single connection to the WAN → buffer a single copy → deliver separate instances to the plurality.
• § 102 assessment:
  • Potentially reads on claim 25's inbound half — receive requests from plural subscribers → aggregate → send one upstream request to the source → receive → fan back out. Bowers is structurally the closest analogue to claim 25's "aggregate → request superset → receive superset → distribute" loop.
  • Fails the "different data" limitation of claims 1/9/17 and the "different information … superset" limitation of claim 25 on the disclosed embodiments, because Bowers aggregates duplicate requests for the same stream (its whole point is de-duplication/multicast). It therefore does not disclose forming a superset of distinct data items of one provider. → Strong § 103 combination material, not a clean § 102 anticipation.
  • Also relevant to claim 4/12/20 (receiver-specific vs. shared streams) and to the "assemble data" step.
• Confidence: High on content; moderate-to-low on § 102 anticipation because of the "same stream" disclosure.

2.3 US 2007/0055615 A1 (Ameritrade IP Company, Inc.) — examiner-cited

• Citation: US 2007/0055615 A1, "System and methods for disseminating real time information" (Howell, Earthman, Singh). Continuation of Ser. No. 09/736,707 → US 7,212,994 B2; also issued as US 7,921,044 B2.
• Dates: priority 2000-12-15; published 2007-03-08. (Priority predates the '782 filing by >3 years, so it is § 102(a)/102(e)-eligible on its face notwithstanding the 2007 publication date.)
• Description (verified this session): A quote server 23 receives real-time stock quotes from an exchange 21 through a field vendor 22. A contact server 26 receives requests from plural trading stations 25a–25n; the contact server requests the quote from the quote server; the quote server returns it; the contact server disseminates the quote to all traders who requested it (and only to them).
• § 102 assessment:
  • Potentially reads on claims 1/9/17's "receiving information preferences from a plurality of subscribers," "dynamically changing information," "transmit … to the data source provider," "assemble data," and on claims 5/13/21 (send only to those who requested/are active) — and it is a mobile/real-time information dissemination architecture.
  • Does not clearly anticipate the "at least two … correspond to different data of said same data source provider" hook of claims 1/9/17, nor the "superset of … different information" hook of claim 25: the disclosed embodiment amplifies a single requested symbol to all requesters. → § 103, with the "different data" element supplied by another reference (e.g., Nanja or a multi-source aggregator).
  • Note the domain gap: it is a brokerage/trading system, not a wireless "mobile information system" with subscriber channels — a secondary § 102 weakness.
• Confidence: High on content; moderate on anticipation.

2.4 US 2002/0146008 A1 (International Business Machines Corp.) — examiner-cited

• Citation: US 2002/0146008 A1, "System and method for a multicast network messaging service" (granted as US 7,054,276 B2).
• Dates: filed 2001-02-07; published 2002-10-10; granted 2006-05-30.
• Description (verified this session): Multicast distribution of a message from a publishing/first machine through a network of message-processing machines to one or more subscribing/receiving machines, using cells and link bundles and a spanning tree. Claims recite delivering the message to each receiving machine in receiving cells and forwarding to subscribing neighbors.
• § 102 assessment: Directed to multicast transport/topology, not to aggregating subscriber preferences upstream to a data source provider. Potentially relevant to claim 4/12/20 (delivering a stream to multiple subscribers) but it does not disclose receiving "information preferences," channel separation, or per-subscriber content disaggregation. → § 103 / background art, not anticipation of any independent claim.
• Confidence: High on content; low on anticipation.

3. Tier 2 — references mapped to specific dependent limitations

Content for these is taken from the record's titles/assignees and my general knowledge; I did not full-text-verify each this session. Treat the mapping as a lead, not a conclusion.

(Rows with no meaningful mapping are marked peripheral; I did not invent descriptions for references whose content I could not verify.)

4. Tier 3 — the remaining face citations (mostly bandwidth/QoS/streaming backdrop)

The bulk of the 59 citations cluster into three unrelated families, none of which touches the preference-aggregation-to-source-provider core of claims 1/9/17/25:

• QoS / bandwidth / scheduling / admission control — US 6,640,248; 6,686,?; 6,687,224; 6,818,669; 6,882,623; 7,031,254; 7,031,306; 7,092,358; 7,096,016(n/a); 7,190,670; 7,225,267; 7,263,635; 7,324,540; 7,334,717; 2003/0084184; 2003/0093515; 2005/0177633; and the RFC-based NPL (RFC 3312, 3521, 3583, 3644, 3334, 3670) plus the QoS papers (Almajano; Chao & Liao; Sevanto). These were cited almost certainly as § 112 support / § 103 backdrop for the bandwidth-gating dependent claims (6, 14, 22) — the same art pool that appears in the sibling "BANDWIDTH MANAGEMENT SYSTEM" application (Ser. No. 10/791,311).
• Network/content delivery and multicast plumbing — US 5,751,968; 6,002,675; 6,578,068; 6,732,179; 6,976,090; 7,043,?; 7,054,? (see IBM above); 7,192,244; 7,221,147; 7,254,605; 7,254,607; 7,337,?; 2002/0078158; 2002/0106998; 2003/0093530; 2007/0094086. Mainly background/§ 103.
• Interactivity/user-resource control — US 6,732,179 (At Home, restricting access to user resources); 2002/0073232 and its grant US 7,177,945 (Hong/Avaya). Peripheral to the claims.

None of Tier 3 anticipates an independent claim. Most could support at best a § 103 combination, and even then only against the dependent bandwidth/connection limitations.

5. Non-patent citations (12)

Observation: the NPL set is overwhelmingly QoS/bandwidth-themed — again consistent with the bandwidth-management sibling, not with the aggregation architecture of claims 1/9/17/25. The three file-history items are not prior art (they are prosecution documents from the co-pending sibling application, submitted under the duty of disclosure).

6. § 102 vs. § 103 — the honest bottom line

No single citation in the 59-reference list appears to disclose every limitation of any independent claim. Two elements in particular kept the independent claims out of clean § 102 anticipation:

1. "At least two of said aggregated information preferences correspond to different data of said same data source provider" (claims 1, 17) and "for different information available from one of said at least one data provider to form a superset" (claim 25). The best structural analogues — Bowers (de-duplication of the same stream) and Ameritrade (amplification of a single quote) — both aggregate identical requests, so they disclose aggregation without the "different data / superset" feature.
2. "Dynamically changing information" + mobile-information-system/subscriber-channel context. Ameritrade's data is dynamic but in a brokerage context; Nanja's aggregator is per-user, not a multi-subscriber service.

Accordingly:

• Best § 102 candidates (partial, dependent-claim level): Nanja 2002/0107830 against claims 7, 8, 15, 16, 23, 24 (XML + XSL transform); Bowers 2003/0005455 and Ameritrade 2007/0055615 against claims 4, 5, 12, 13, 20, 21 (subscriber-specific distribution / only-to-requesters).
• Best § 103 combinations against the independent claims: Bowers or Ameritrade (aggregate-request/disaggregate architecture) + Nanja (XML/XSL acquisition, per-source data), optionally + a processor/bandwidth reference for the dependent bandwidth claims.
• Tier 3 references (the majority): prior art for the bandwidth/QoS dependent claims (6, 14, 22) only.

Confidence: High that the set of references contains the building blocks for the examiner's § 103 rejections and for the dependent claims. Moderate on the precise § 102-anticipation calls against the independent claims, because (a) I verified full content for only 4 of 59 references this session due to a tool-step limit, and (b) I could not pull the actual prosecution file history (IDS / examiner's rejections), which would show exactly which reference was mapped to which claim. To make this a certified mapping, pull the file wrapper of 10/791,299 (PTO-892, non-final/final Office Actions, examiner's art cited) from USPTO Patent Center, and confirm the reference contents against the claim charts above.

7. Important disambiguation (per the "no auto-correct" rule)

The literal identifier 7706782 is uniquely US 7,706,782 B1. Do not conflate it with items that surfaced during verification of nearby numbers: US 5,207,678 (DePuy v. Medtronic pedicle screw); US 6,757,828 (Jaffe v. Adobe); 7,707,624, 7,258,178, 7,177,798; or the Westlaw cite "2020 WL 7706782" (Rural & Migrant Ministry v. EPA). None of these is US 7,706,782, and none of the instant patent's citations.

Sources: https://patents.google.com/patent/US7706782B1/en ; https://www.freepatentsonline.com/7706782.html ; https://patents.justia.com/patent/7706782 ; https://portal.unifiedpatents.com/patents/patent/US-7706782-B1 ; https://patents.google.com/patent/US20020107830 ; https://patents.google.com/patent/US20030005455A1 ; https://patents.google.com/patent/US20070055615 ; https://patents.google.com/patent/US7054276 (US 2002/0146008 A1).

I'll ground this analysis in the actual prior-art references of record, then build the § 103 combinations. Let me pull details on the most probative references from the patent's own "Patent Citations" and "Non-Patent Citations" sections.

Good — I have solid detail on Murthi, Bowers, the IBM multicast application, and Motorola '022. Now let me verify the remaining examiner-cited references I plan to combine, plus the "real-time information" and bandwidth references.

Obviousness Analysis — US 7,706,782 B1 under 35 U.S.C. § 103

Scope note: Per instruction, I used only the prior-art materials appearing on this page's own Prior Art section — (a) the background art described in the patent's own specification, (b) the 59 "Patent Citations," (c) the 12 "Non-Patent Citations," and (d) the AB1/AB2/AB3 designation (* = cited by examiner). I did not introduce outside art. Where I could not verify a reference's disclosure text in this session, I say so explicitly. This builds on the prior Litigation and Summary sections rather than repeating them (those establish: filed/priority 2004-03-01, issued 2010-04-27, expired 2025-02-03, never litigated, four independent claims 1/9/17/25 + claim 26).

Governing law: Pre-AIA § 103 (application filed 2004-03-01), so Graham v. John Deere factors plus the KSR Int'l Co. v. Teleflex Inc. (2007) framework — the patent issued in 2010, i.e., after KSR, so the flexible "any need or problem known in the field" motivation standard was available to the examiner.

1. The prior art of record and what each teaches

2. The pivotal limitation, and the combination that meets it

Claim 1's narrowing hook is the clause:

"…wherein at least two of said aggregated information preferences correspond to different data of said same data source provider."

This requires cross-subscriber aggregation of distinct data items against a single origin. Two references split this requirement, which is precisely the KSR situation:

• Murthi teaches aggregating distinct data items (weather + stocks + news) and XML/XSL delivery to a wireless handheld — but the aggregation is per-user, across sources.
• Bowers teaches aggregating multiple users' requests against one source into a single upstream request, then generating receiver-specific downstream streams — but the requests are for the same media.

Motivation to combine (strong, and rooted in the patent's own admissions):

1. Both references pursue the identical engineering objective — minimizing redundant network traffic and repeated connection sessions on constrained wireless/cable links. Murthi: "communicated to the wireless device in a single connection session"; Bowers: adding connections "reduce[s] the available network resources."
2. The patent's own background supplies the problem statement: POINTCAST's one-to-all broadcast "clogged networks." Aggregating demand at the server rather than broadcasting everything is the ordinary engineering response to that known problem (KSR: "a need or problem known in the field of endeavor").
3. The combination is a predictable, two-step substitution: Bowers' aggregation module is placed in Murthi's intermediary "information hub"/system 103; Murthi's XML/XSL content pipeline supplies the payload type. No reference teaches away; Murthi's system explicitly serves plural wireless units (101).

Claim 1 chart (proposed rejection: Murthi + Bowers, further in view of Motorola '022):

3. Claim 25 / 26 — the strongest § 103 combination

Claim 25 recites the enhanced-broadcast-server version: receive subscriber preferences → aggregate into a superset for one data provider → request the superset → receive it → determine subsets per subscriber → send subsets out.

Ameritrade (US 2007/0055615 A1) alone nearly reads on this:

• "contact server 26" ≡ enhanced broadcast server; "quote server 23" ≡ data provider (both "communicatively coupled");
• contact server requests quotes "in response to the stock quote request being requested by at least one user" — i.e., aggregates demand upstream;
• quote server "sends a stock quote to the contact server only when a stock quote request has been made" — the superset request;
• "the contact server disseminates the quote to the user and two other users requesting the same quote" — the subset determination and fan-out;
• express motivation: reduce load on the data provider ("the quote server … can dedicate more processing for receiving new stock quote information").

The only material gap is that Ameritrade's requesters are brokerage trading stations 25a–25n on a LAN/WAN, not mobile subscribers. Murthi (and Motorola '022) supply mobile/wireless delivery and the XML/XSL formatting, and both are examiner-cited art in the same field. Combining an aggregation/redistribution architecture with a mobile delivery channel is the predictable use of a known technique for its known purpose — the core KSR rationale. Claim 26 (aggregating received information from different data providers for one subscriber) is met by Murthi's express aggregation of stocks and weather and news from different web servers 105.

4. Dependent claims

5. Motivation-to-combine synthesis (§ 103 rationale statement)

A PHOSITA in March 2004 (mobile data services; XML/XSL content pipelines; server-side aggregation/proxies) would have been motivated to arrange these references as claimed because:

1. Same field, same problem, same result. All of Murthi, Bowers, IBM '008, and Ameritrade target redundant traffic and constrained links; the patent's own background concedes the POINTCAST broadcast "clogged networks." Aggregating demand upstream to a single request is the explicit solution Bowers and Ameritrade state.
2. Predictable improvement with no changed principle. Substituting a multi-user aggregation front end (Bowers/Ameritrade) onto a wireless XML delivery back end (Murthi/Motorola '022) merely widens the input fan-in; the downstream per-receiver distribution machinery already exists in both.
3. Design incentives: bandwidth cost and latency. Murthi's "single connection session," Bowers' "available network resources," and Ameritrade's "the quote server … can dedicate more processing" are mutually reinforcing, and the patent's background decries per-minute cellular charges and click-and-wait latency.
4. Enablement at the time of filing. XML/XSL, HTTP polling, proxy/cache servers, and QoS/bandwidth-policy RFCs (all cited on the face) were mature — no undue experimentation.
5. Prior art of record. Murthi, Bowers, IBM '008, Ameritrade and Ta are all examiner-cited (*), so they are not merely cumulative; they were before the examiner.

6. Weaknesses in the obviousness case (adversarial view)

• The examiner already considered these references and still allowed the claims (issued 2010, post-KSR). Any § 103 attack must therefore rest on a combination or motivation not advanced during prosecution, or on art not of record. Murthi's per-user aggregation and Bowers' same-content aggregation each leave a gap that the claim's "different data of said same data source provider" clause exploits.
• The "superset/subset" framing in claim 25 is genuinely recited, and Ameritrade's disclosure, while close, must be coupled with a mobile-delivery teaching; a patentee would argue the contact server's "same quote to several users requesting the same quote" is same-item, not superset-of-different-items aggregation.
• Means-plus-function claim 9 is presumptively limited under § 112(f) to the disclosed structures (enhanced broadcast server 401; data providers 402-1–402-N) and equivalents — narrowing the practical exposure of that claim. Claims 1, 17 and 25, however, are not so limited.
• Secondary considerations: the record shows no evidence (no litigation, no licensed/industry-adoption narrative) of unexpected results, industry praise, or long-felt need. The absence of evidence cuts against a patentee, but the absence of a commercial-success story also removes a nonobviousness argument.
• § 102(e) timing caveats: For Ameritrade, this page's Google Patents entry lists priority 2000-12-15, while one search result elsewhere states Ser. No. 09/736,707 was filed Dec. 12, 2000 ("[t]his application claims priority to … Ser. No. 09/736,707, filed on Dec. 12, 2000") — I flag the discrepancy rather than reconcile it. Either date precedes 2004-03-01, so it qualifies as pre-AIA § 102(e) art if it properly supports the relied-upon disclosure. Motorola '022 qualifies as § 102(e) art as of its 2000-09-20 filing.

7. Bottom line

1. Claim 1 is the most vulnerable independent claim to a § 103 rejection over Murthi + Bowers (with Motorola '022 / the admitted POINTCAST background for the mobile-channel context), because that pair collectively supplies every element — including the "different data of the same source" clause — with a bandwidth/latency motivation that the patent's own Background endorses.
2. Claims 25 and 26 are vulnerable to Ameritrade (US 2007/0055615 A1) in view of Murthi — Ameritrade supplies the superset/subset server architecture and the load-reduction motivation; Murthi supplies the mobile/XML delivery missing from Ameritrade's LAN-based trading stations.
3. Dependent claims 2–8, 10–16, 18–24 are highly likely obvious: channels (Motorola '022), open-session gating (Murthi's connect-triggered synchronization), bandwidth limits (the six QoS RFCs plus the rate-control/bandwidth references), and XML/XSL formatting (Murthi's CGI-generated XML + XSL stylesheets, which map closely onto claims 7–8).
4. Practical framing: given the patent is expired (2025-02-03) and never litigated (per the Litigation section), this analysis is a validity/prior-art laboratory exercise — useful for defensive citation and for the family's continuation (US 8,064,890 B1) — not a prospective invalidity defense in a live case.

Confidence: High on the claim mappings to Murthi and Bowers (I read their disclosures directly). Moderate-to-high on Ameritrade (I verified its architecture and motivations via multiple listings, but did not inspect the original specification in full). Low on the exact disclosures of US 2004/0199635 (Ta), US 7,376,414 (Varia Mobil), US 7,330,717 (Lucent), and US 2002/0078158 (Brown) — for these I have only the titles/assignees shown in this page's citation list and must not attribute specific teachings to them. The six QoS RFCs are cited for the general policy-accounting/bandwidth-enforcement point only; I did not read them in this session.