US 8024290

I'll search for information on this specific patent number.

Let me refine my search for USPTO records and any CAFC litigation.

Let me do a final targeted check for any appellate or PTAB activity involving this specific patent.

US 8,024,290 B2 — "Data synchronization and device handling"

Searches run: Google Patents (authoritative full text supplied), FreePatentsOnline, Justia Patents, patentimages PDF of the issued patent, plus targeted CAFC docket/opinion search queries for the number. No CAFC 2026 activity for this patent was surfaced (see §5).

1. Bibliographic identification

2. Abstract (as issued)

A synchronization server includes logic operable to engage in a first synchronization session with a client device, in which client modifications and server modifications are exchanged, the server modifications based at least in part on synchronization data stored locally. The server further includes logic operable to initiate a query of a remote database having data associated with the synchronization data to determine differences between the locally stored synchronization data and the remotely stored associated data, and to initiate an exchange of further server modifications based on those differences. In one example, the server engages in a second synchronization session with the client device to update the client device with the differences.

3. Independent claims in plain language

The patent has three independent claims — 1, 10, and 19 (claims 2–9, 11–18, and 20–27 are dependent).

Claim 1 — Synchronization server (apparatus). A synchronization server comprising a data storage and a processor that:

1. Engages in a first synchronization session with a client device, exchanging client modifications and server modifications, where the server modifications are based at least in part on synchronization data stored locally on the server's own data storage;
2. Determines the client modifications at least in part from a digest — the digest distinguishes which client modifications are genuine changes by the user from changes that are artifacts of the client device's characteristics (e.g., truncation/format coercion);
3. In response to the first session, initiates a query of a remote database on a backend server to find differences between the locally stored synchronization data (relating to that client device) and the associated data stored remotely; and
4. Initiates exchange of further server modifications to the client device based on those differences.

In short: answer the client fast from local state, then reconcile with the authoritative backend and push the delta back down.

Claim 10 — Method. The same four-step sequence performed "using a synchronization server": engage in the first sync session (server modifications based on locally stored synchronization data); determine client modifications via a digest distinguishing user changes from device-characteristic changes; in response to the first session, query the remote backend database for differences; and exchange further server modifications based on the differences. The claim is written at the method level but is otherwise coextensive with claim 1.

Claim 19 — Computer-readable storage medium. A non-transitory-style "computer-readable storage medium comprising computer-readable instructions tangibly stored thereon" for assisting data synchronization between a client device and a synchronization server using a remote database, containing program code configured to perform the same four functions: (i) engage in the first synchronization session with the locally based server modifications; (ii) determine client modifications via the digest; (iii) initiate the backend query for differences; and (iv) exchange further server modifications based on the differences.

Notable dependent-claim coverage (context for the independent claims): second synchronization session, optionally responding to a client request (claims 2–3); notifying the client of updates after the first session (4); initiating a slow synchronization process, wherein the slow sync compares Locally Unique Identifiers (LUIDs) and Cyclical Redundancy Checks (CRCs) of data items rather than going field-by-field (5–6); modulating synchronization data based on the client device, including device capabilities (7–8); and sending an empty sync / "keep alive" message (9).

4. Context from the specification (not claim scope)

The specification frames the invention as (a) a short first session answered from local inventory/digest state to reduce session length and session-failure risk, followed by backend reconciliation and either a notification (e.g., SMS/WAP-Push) or a client-polled second session; and (b) a "slow sync optimization" that avoids full field-by-field comparison by using pending server modifications plus an inventory of LUIDs and CRCs. The digest (indexed by IMEI or similar device identifier, with per-entry LUID) preserves data the device compressed or truncated, so the server can distinguish user edits from device-imposed transformations. Figure 1 is labeled prior art; Figures 2–5 are the described examples.

5. CAFC 2026 dockets — result of the search

I found no Federal Circuit 2026 docket entry, opinion, Rule 36 judgment, or scheduled oral argument involving US 8,024,290. Targeted CAFC-oriented queries returned only unrelated matters (e.g., Centripetal Networks v. Keysight, No. 2024-1930, Rule 36 judgment dated January 12, 2026; the Ex parte Baurin ODP amicus activity; Headwater Research v. Verizon appeal Nos. 26-1884 and cross-appeal from E.D. Tex. 2:23-cv-00352). None of these involve the '290 patent.

Caveat: I do not have direct, authoritative access to a live CAFC docket system or to Docket Navigator/PACER within these searches. Absence of results is therefore not proof that no 2026 proceeding exists — it means nothing surfaced. No PTAB post-grant proceeding for this patent was found either.

6. Explicit cautions on lookalike identifiers (interpreted literally, not auto-corrected)

Several near-identical strings appear in the search results and must not be conflated with US 8,024,290:

• U.S. Patent No. 9,820,429 ("the '429 patent") — a John Deere seeding/planter patent at issue in IPR2019-01052 and related PTAB filings (Precision Planting v. Deere). A different patent in a different technology; the shared "429" suffix is coincidental.
• JP 8024290 — a Japanese publication dated January 30, 1996, cited as a foreign abstract in unrelated justia pages.
• U.S. Patent No. 8,024,290 (this patent) is also cited in the "Cited By" lists of later patents, e.g. US 10,623,490 B2 ("Optimizing a slow synchronization package," IBM, priority 2003-12-29), which is topically adjacent (slow-sync optimization) and worth noting for any invalidity/prior-art landscape work.

7. Bottom line

US 8,024,290 is a Yahoo-origin (now Verizon-held) SyncML data-synchronization patent filed and issued in 2005/2011, with three independent claims (1, 10, 19) covering: local-first synchronization response, digest-based discrimination of user edits vs. device-characteristic edits, post-session backend reconciliation, and pushing further server modifications (optionally in a second session). Legally it is listed as expired for fee non-payment, with an adjusted expiration of 2028-11-25. No CAFC 2026 docket activity for this specific number was found, and I cannot independently confirm docket absence beyond the searches performed.

I'll research litigation involving US patent 8024290. Let me run several targeted searches.

Initial broad searches returned mostly unrelated hits. Let me search litigation-specific databases and the patent's known corporate history.

Litigation Search Report — US Patent No. 8024290

Patent: US 8,024,290 B2 — "Data synchronization and device handling"
Inventors: Lie Yang, John A. Traver, Venkatachary Srinivasan, Marco Boerries
Original assignee: Yahoo! Inc. (later Yahoo Holdings, Inc. → Oath Inc. → Verizon Media Inc. → Verizon Patent and Licensing Inc.)
Filing/priority date: 2005-11-14 | Granted: 2011-09-20
Status: Expired – Fee Related (adjusted expiration listed as 2028-11-25)

Result: No litigation identified

Based on my searches, I found no evidence of any patent infringement litigation (district court, ITC, CAFC appeal, or PTAB post-grant proceeding) involving US Patent No. 8024290.

Searches across general web, patent-document repositories, USPTO PTAB dockets, and litigation-content sources surfaced no case caption, docket number, complaint, or party list naming this patent. I was not able to retrieve results from the Unified Patents litigation portal (portal.unifiedpatents.com) — my query against that domain returned no matching results, so I could not confirm or rule out a listing there.

Important caveat on identifier collisions

Per the rule to interpret alphanumeric identifiers literally and not auto-correct them, I note that the string "8024290" matches several unrelated identifiers that should not be confused with the US patent:

• JP 8024290 — a published Japanese patent abstract (Jan. 30, 1996), cited in the prosecution history of Kimberly-Clark patents (see Justia, US 8,622,984).
• Brazilian municipal publication No. 8024290 — a 2026 administrative order from Porto União, SC (dom.sc.gov.br).
• Various commercial/registration numbers (e.g., Brazilian corporate records) that coincidentally contain the digits.

These are not the US patent and are excluded from the litigation analysis.

Why the absence of litigation is plausible

Consistent with the docket history, the patent:

• Is Expired – Fee Related (maintenance fees not paid), meaning the enforceable term ended early and the asset has little or no remaining enforcement value; and
• Was held by Verizon Patent and Licensing Inc. (via the Yahoo/Oath/Verizon chain) — a large operating company rather than a litigation-focused NPE. Verizon's Yahoo-derived portfolio has generally not been asserted in the campaigns that produced frequent litigation on other Yahoo patents.

Confidence and limitations

• Confidence that no litigation exists: moderate. The absence of hits is consistent across multiple independent queries, and the expired status makes a suit very unlikely, but I could not complete direct verification through PACER, Docket Navigator, or the Unified Patents caselist (the latter returned an empty result set).
• I do not have high-confidence, verifiable data on any specific case (plaintiff, defendant, court, case number, filing date, outcome) because none was found.
• If a definitive confirmation is required, the authoritative next steps would be a direct search of PACER (all district courts) and the CAFC docket for "8,024,290," plus a query of PTAB P-TACTS for any IPR/PGR/CBM challenging the patent.

Bottom line: As of today (April 26, 2026), I have no known litigation to report involving US 8,024,290, and no case-level details (plaintiff, defendant, jurisdiction, case number, filing date, or outcome) can be provided.

I'll verify the structured ODP result against public sources before concluding.

Let me run additional targeted checks before concluding.

Proceedings overview

Total AIA trial proceedings on US 8,024,290: zero. The structured "PTAB proceedings on file" block — sourced from the USPTO Open Data Portal — returns no IPR, PGR, or CBM for this patent, and my independent web searches surfaced none either. There is therefore no breakdown to give by status: no proceeding is active, none invalidated claims, none sustained claims, none settled, and none was denied institution.

Bottom line for a defendant: the patent is entirely untested at the PTAB. That is a two-edged posture. It is not "hardened" — no panel has ever construed claims 1, 10, or 19, so you have no adverse claim-construction record to fight and no § 315(e) estoppel running against you. But it is also not "dead" — the troll (or, realistically, Verizon Patent and Licensing Inc.) can assert all 27 claims free of any prior PTAB cancellation. The untested status is purely a function of non-assertion: well-asserted patents reliably attract IPRs, and a Yahoo-origin SyncML patent that has been through four corporate reassignments without a single AIA petition suggests it has never been a meaningful litigation target.

No proceedings found — verification steps taken

I could not generate per-proceeding entries because there are no proceeding numbers to populate. To avoid fabricating any, here is what I checked:

Caveat, stated plainly: I do not have live, authenticated access to PTAB E2E or Docket Navigator. The ODP "no proceedings" result plus the absence of any indexed petition is strong evidence of no AIA trial activity, but absence of search results is not affirmative proof. A patent owner's internal docket or a PACER/E2E pull would be the definitive check.

Explicit lookalike warnings (do not conflate)

My searches repeatedly returned three different patents whose numbers resemble 8,024,290. None of them is this patent:

1. U.S. 8,023,290 (SynQor) — power-converter patent at issue in Vicor Corp. v. SynQor, Inc., Nos. 2021-2211 and related, and in the inter partes reexaminations affirmed in SynQor, Inc. v. Vicor Corp., 869 F.3d 1309 (Fed. Cir. 2017). Digit transposition of 8,024,290. Different technology, different owner, different proceedings. The Fed. Cir. opinions in that line say nothing about the Yahoo patent.
2. U.S. 9,820,429 (Deere) — seed-planter patent at issue in Precision Planting v. Deere, IPR2019-01052 and related. Shared "429" suffix only.
3. JP 8024290 — unrelated Japanese publication string.

Any research memo that cites "the '290 patent" from the SynQor line as if it were US 8,024,290 is citing the wrong patent.

Strategic summary

Which claims are canceled vs. sustained vs. untested. Every claim — 1–27, including all three independents (1, 10, 19) — is UNTESTED. None is canceled; none has been confirmed. There is no surviving-claim list to compile because no claim has been narrowed by any post-grant proceeding. The only narrowing of record is whatever occurred during prosecution (the pre-grant publication US 2007/0112880 A1 issued as US 8,024,290 B2 with 27 claims and 4 drawing sheets).

Estoppel landscape — the field is empty. Because no FWD has ever issued, § 315(e)(2) estoppel attaches to no one with respect to this patent. A defendant today faces no estoppel shadow at all and may raise § 102/§ 103 grounds in district court freely. Correspondingly, if you file an IPR that reaches FWD, you will be estopped from re-litigating at trial any ground you raised or reasonably could have raised. The other statutory gates still apply and are the real constraints:

• § 315(b) one-year bar — if you (or a privy/RPI) were served with a complaint alleging infringement more than one year ago, IPR/PGR is time-barred. A bare demand letter does not start the clock.
• § 325(d) — the Board may discretionarily deny on art previously considered by the examiner. The '290 file's own IDS/prior-art citations (the slew of Yahoo "Content Router"/"blade architecture" publications listed under "US Patent References" on the face of the patent) are exactly the art most exposed to a § 325(d) denial, so a petition should lead with new art.
• Fintiv / discretionary denial — if there is a parallel district court case with a trial date near the FWD deadline, expect a Fintiv fight absent a Sotera stipulation.

Pattern signals. No petitioner has filed anything — not one, not multiple. No Unified Patents or other defensive aggregator appears anywhere in the chain. The patent owner has never had a claim to appeal, so there is no PTAB-appeal history. The assignment chain is entirely ordinary corporate succession: Yahoo! Inc. → Yahoo Holdings (2017-06-23) → Oath (2018-02-02) → Verizon Media (2020-10-26) → Verizon Patent and Licensing (2021-08-19). Notably, even the largest Yahoo/Verizon-era assertion campaigns (e.g., the Verizon–Huawei W.D. Tex. disputes) did not put this patent in suit or in an IPR, which is itself informative about its perceived litigation value.

Status caution (flagged, not resolved). Google Patents lists US 8,024,290 as "Expired – Fee Related" with an "adjusted expiration" of 2028-11-25 and a § 154(b) term adjustment of ~1107 days. Those two data points are in tension: a fee-related lapse normally means the patent terminated early for non-payment of maintenance fees, whereas a 2028-11-25 adjusted expiration implies it ran to term. I cannot reconcile them from the sources available; treat the fee-lapse characterization as an assumption, per Google's own disclaimer. Practically: an expired or lapsed patent can still be asserted for past damages within the six-year lookback of § 286, so expiration alone is not a complete defense. Note also that for an expired patent the Board applies Phillips-style claim construction rather than the BRI standard, which changes how you brief any petition.

Recommended next steps

1. State the negative plainly to the client. There is no IPR, PGR, or CBM on US 8,024,290. Do not represent that claims have been canceled. Any clearance or defense opinion must be built on an independent invalidity analysis, not on an inherited PTAB record.
2. Confirm the negative authoritatively. Pull the patent in PTAB E2E (https://ptab.uspto.gov) and Patent Center to confirm no AIA trial and to pin down the true legal status — specifically whether maintenance fees were actually paid and, if lapsed, the lapse date. That date drives the § 286 back-damages window.
3. Check the § 315(b) clock immediately. If your client was served with an infringement complaint more than one year ago, an IPR is time-barred and the defense shifts entirely to § 282 at trial. If only a demand letter was received, the IPR window is wide open — and with no estoppel and no prior adverse construction, this patent is a clean IPR target.
4. Prior-art leads worth developing before filing (all leads, not conclusions):
   • The SyncML Sync Protocol v1.1.1, OMA, October 2, 2002 — expressly incorporated by reference in the '290 background at column 1. It is a printed publication predating the 2005-11-14 priority date and is a natural § 102(b) anchor for the local-first sync and sync-anchor (claims 1, 10, 19) concepts.
   • US 10,623,490 B2 (IBM, "Optimizing a slow synchronization package"), priority 2003-12-29 — this patent cites US 8,024,290, so its underlying earliest-priority application predates the '290 filing date and may qualify as § 102(e)/§ 102(a)(2) art against the LUID/CRC slow-sync claims (claims 5–6, 15–16, 23–24). Verify the priority chain before relying on it.
   • US 2007/0088764 A1 (Yoon et al.), "Method and apparatus for synchronizing multimedia content with device which supports multi-server environment," and US 7,139,983 (Kelts), both cited on the face of the '290 patent — potential § 325(d) exposure, so use them as claim-construction context rather than primary grounds.
   • The related Yahoo "Content Router" family (Ser. Nos. 11/182,287 and 11/264,121, both incorporated by reference into '290) — these are the applicant's own earlier-filed work on the same routing/modulation architecture, which may supply § 102(a)(2) art on the digest/transcoding limitations of claim 1.
5. Watch for a companion patent. The family includes US 2008/0270629 A1, "Data synchronization and device handling using sequence numbers" (Yahoo, filed 2007-04-27), which cites the '290 patent. If Verizon later asserts the sync family, expect that application's resulting patent to be asserted alongside '290 — build the invalidity case on the shared SyncML foundation once, not twice.

If PTAB activity does appear later, the milestones to calendar are statutory: an institution decision within ~6 months of the preliminary response due date, and a final written decision within 12 months of institution under § 316(a)(11), extendable only for good cause under § 316(a)(11)'s safe harbor.

Sources consulted: Google Patents record for US 8,024,290 (bibliographic, claims, cited-by lists); FreePatentsOnline entry for 8024290; PTAB E2E / USPTO PTAB Decisions and CourtListener (queried; no '290 materials returned); the ODP structured block supplied in this prompt. No FWD, institution decision, or settlement order exists to link.

I'll research the assignment records for this patent, starting with targeted searches for USPTO assignment data.

Inventors

All four named inventors are listed on the face of the issued patent (US 8,024,290 B2) with California addresses, and they are expressly identified in the recorded inventor-side assignment (Google Patents legal event dated 2006-02-03, "ASSIGNMENT OF ASSIGNORS INTEREST," assignors SRINIVASAN, VENKATACHARY; BOERRIES, MARCO; TRAVER, JOHN A.; YANG, Lie):

Pattern notes / limitation. The patent was filed 2005-11-14, i.e., during the same Yahoo "Connected Life" / content-sync build-out year as the related applications cited on the cover (Ser. Nos. 11/182,287 and 11/264,121, both 2005). All four inventors assigned to Yahoo! Inc. contemporaneously, which is the ordinary operating-company pattern (no inventor-retention, no individual-assignee gap). I could not retrieve data on inventor departure dates relative to filing, so I cannot confirm or rule out the "all inventors depart within 12 months" fire-sale precursor. I am flagging that as not verifiable from the sources retrieved rather than asserting it either way. (Note: the co-pending applications named a broader Yahoo content-router team — Schulz, Ebbesen, Tendjoukian, Breuer, Meyer — whose surnames do not appear on this patent's inventor list.)

Original assignee

Yahoo! Inc. (Sunnyvale, CA), a Delaware corporation — the entity named on the issued patent.

• Primary line of business: consumer internet portal/search, webmail (Yahoo! Mail), and — directly relevant here — a mobile synchronization platform. The patent specification itself describes server-side SyncML synchronization of Contacts/Calendar between mobile devices and a Yahoo! user account backend (remote database 40, "Yahoo!® user account"), so the asserted subject matter maps onto an actual Yahoo product/service (Yahoo! mobile sync / address-book and calendar sync).
• Did it ship a product embodying the claims? Yes, on the face of the disclosure: the specification expressly describes the Sync server answering a SyncML client from local inventory/digest state and reconciling against a Yahoo! backend (FIGS. 2–4), which is the claimed local-first-then-backend-reconcile flow. This is an operating-company-origin patent, not a paper patent.
• Current status (entity-level nuance):
  • The operating business of Yahoo! Inc. was transferred to Yahoo Holdings, Inc. effective 2017-06-13 (corroborated by Droplets, Inc. v. Yahoo!, Inc., N.D. Cal. No. 4:12-cv-03733-JST, Dkt. 327/333/349, and AlmondNet, Inc. v. Oath Holdings, Inc., D. Del. No. 1:19-cv-00247) and then sold to Verizon Communications via the ~$4.4B stock purchase.
  • The residual Yahoo! Inc. (the entity retaining Alibaba/Yahoo-Japan stakes) was renamed Altaba Inc. and wound down/dissolved. This was a controlled liquidation of the parent, not a bankruptcy (no Chapter 7/11 proceeding found).
  • Separately, the "Yahoo" brand re-emerged: Verizon Media was sold to Apollo in 2021 and rebranded Yahoo Inc. — a different entity from the 2005 assignee. Watch for name collisions here.

Assignment timeline

Sourcing limitation — read first. I was able to retrieve this patent's assignment events (conveyance type, assignor, assignee, and recording dates) from the Google Patents legal-events record embedded in the authoritative full text supplied for this analysis. I was not able to pull the underlying USPTO Assignment Center records (reel/frame, execution date, and correspondent of record) through the available search tooling — repeated queries against assignment.uspto.gov, assignmentcenter.uspto.gov, and uspto.report returned no record-level data for this number. Accordingly, I am not supplying reel/frame numbers or correspondent names, because doing so would require fabrication. Where a field is unknown, it is marked not retrieved. The chain below should be verified directly at the Assignment Center before any filing/standing use.

Dates below are recording dates as listed in the Google Patents legal-events record unless the calendar notice says "executed."

1. Executed on/around 2005-11-14 (filing date); recorded 2006-02-03 — Reel/Frame not retrieved

   • Conveyance: Assignment of assignors' interest (inventor → company)
   • Assignor: Srinivasan, Venkatachary; Boerries, Marco; Traver, John A.; Yang, Lie
   • Assignee: YAHOO! INC.
   • Correspondent: not retrieved (do not assume; the patent's face lists prosecution counsel James J. DeCarlo / Greenberg Traurig, LLP, which is likely — but not confirmed — to be the recording firm)
   • Context: Standard employee/inventor assignment to the operating company at filing — no NPE significance.

2. Recoded 2017-06-23 — Reel/Frame not retrieved

   • Conveyance: Assignment of assignor's interest
   • Assignor: YAHOO! INC.
   • Assignee: YAHOO HOLDINGS, INC.
   • Correspondent: not retrieved
   • Context: Internal corporate reorganization — transfer of the operating business into the Verizon-purchase vehicle; execution date corroborated as effective 2017-06-13 by the Droplets and AlmondNet filings.

3. Recorded 2018-02-02 — Reel/Frame not retrieved

   • Conveyance: Assignment of assignor's interest
   • Assignor: YAHOO HOLDINGS, INC.
   • Assignee: OATH INC.
   • Correspondent: not retrieved
   • Context: Corporate renaming/rebranding step (Yahoo Holdings → Oath) accompanying the Verizon integration; functionally a change-of-name-type event recorded as an assignment.

4. Recorded 2020-10-26 — Reel/Frame not retrieved

   • Conveyance: Assignment of assignor's interest
   • Assignor: OATH INC.
   • Assignee: VERIZON MEDIA INC.
   • Correspondent: not retrieved
   • Context: Internal Verizon reorganization/rebrand (Oath → Verizon Media).

5. Recorded 2021-08-19 — Reel/Frame not retrieved

   • Conveyance: Assignment of assignor's interest
   • Assignor: VERIZON MEDIA INC.
   • Assignee: VERIZON PATENT AND LICENSING INC.
   • Correspondent: not retrieved
   • Context: Internal portfolio consolidation into Verizon's captive patent-holding subsidiary — the current assignee.

If the Assignment Center confirms no records beyond the five above, that is the finding: the chain is a pure operating-company → holding-company consolidation sequence with no third-party/NPE link.

⚠️ Contradiction check against prior sections: none. The previously generated summary listed the same five-step chain (Yahoo! Inc. → Yahoo Holdings, Inc. → Oath Inc. → Verizon Media Inc. → Verizon Patent and Licensing Inc.) and the litigation section found no assertion of this patent. The Droplets and AlmondNet suits corroborate the corporate reorganization dates but involve other patents (the '745/'838 and '615 patents respectively) — '290 was not asserted in either, which is consistent with, not contrary to, the earlier "no litigation" finding.

Timeline diagram

timeline
    title Ownership of US 8024290
    2005 : Filed by Yahoo Inc
    2006 : Inventors assign to Yahoo Inc
    2011 : Patent issued to Yahoo Inc
    2017 : Yahoo Inc to Yahoo Holdings Inc
    2018 : Yahoo Holdings to Oath Inc
    2020 : Oath Inc to Verizon Media Inc
    2021 : Verizon Media to Verizon Patent and Licensing
    2028 : Adjusted expiration date

NPE / troll-pattern signals

1. Shell-entity transfer — not present. Every assignee in the chain is a large, named operating or captive-holding company (Yahoo! Inc.; Yahoo Holdings, Inc.; Oath Inc.; Verizon Media Inc.; Verizon Patent and Licensing Inc.). No assignee carries an "IP / Patents / Licensing / Ventures" single-purpose-LLC profile of the Acacia/Marathon type. (Caveat: Verizon Patent and Licensing Inc. does not itself sell products — it is a captive patent-holding arm — but a captive holding arm of a $240B operating parent is not a "shell-entity transfer" in the NPE sense used here.) Reel/frame for verification: not retrieved.

2. Known asserter in the chain — not present. None of the five assignees matches any entity on the comparison lists (Acacia, Marathon, IV, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, Spangenberg entities) or, to the extent checkable, a Unified Patents / RPX high-frequency-plaintiff listing.

3. Repeat correspondent across the chain — unclear (data gap). The single most probative field — the correspondent of record on each recording — could not be retrieved. I therefore cannot make the positive finding (a recurring NPE lawyer) and cannot make the negative finding (distinct in-house/outside correspondents per link). This is the one signal where the missing USPTO record matters most; it should be pulled manually. The patent face shows prosecution counsel James J. DeCarlo / Greenberg Traurig, LLP, and Yahoo-family filings elsewhere list attorneys such as Shannon Mo — but these are prosecution/trademark records, not verified patent-assignment correspondents, so neither is a finding here.

4. Cascading transfers — not present as an NPE signal (present only as benign corporate churn). Five recordings span 2006→2021, i.e., >24 months apart between the post-issuance links (2017, 2018, 2020, 2021). Critically, the assignees are vertically related parents/subsidiaries (Yahoo → Holdings → Oath → Verizon Media → Verizon), not an unexplained chain of unrelated LLCs. The <24-month / shared-correspondent / common-principal pattern that defines this signal is not met.

5. Pre-litigation transfer — not present. No infringement suit naming '290 was identified in the prior litigation section, so there is no suit to date any transfer against.

6. Bankruptcy fire-sale — not present. The Yahoo operating-business transfer to Verizon was a ~$4.4B negotiated stock purchase (2016 SPA, effective 2017), and the residual parent (Altaba) wound down by orderly liquidation in 2019–2020. No Chapter 7/11 sale of this patent and no court-supervised patent sale (the Kodak/Nortel/Polaroid paradigm) was found.

7. Privateering — not present. Although Verizon Patent and Licensing Inc. is a non-practicing holding entity for Verizon Communications, there is no evidence of assertion on Verizon's behalf against competitors, and no SEC/Patent-Progress/EFF coverage surfaced tying '290 to a privateering program. The patent is additionally Expired – Fee Related (maintenance fees unpaid; adjusted expiration 2028-11-25), which makes any future assertion economically irrational.

8. Defensive aggregator — not present. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. It terminates at Verizon's own captive holding company, which retains the asset rather than neutralizing it.

Verdict

Defensive / non-asserting. (Nearest fit — see caveat.)

Justification: The recorded chain runs Yahoo! Inc. → Yahoo Holdings, Inc. → Oath Inc. → Verizon Media Inc. → Verizon Patent and Licensing Inc., a five-link intra-family consolidation with recording dates 2006-02-03, 2017-06-23, 2018-02-02, 2020-10-26, and 2021-08-19 — every assignee a large operating or captive-holding company, with zero shell-LLC links, zero known asserters, and zero identified infringement suits involving '290. The patent is additionally Expired – Fee Related, and the prior sections confirm no litigation, so the practical and evidentiary effect is a non-asserted, expired asset held inside Verizon's captive patent entity — not an NPE chain, and not a defensive-aggregator termination either.

Caveat (definitional mismatch, stated explicitly): the enumerated "Defensive / non-asserting" option is defined as a chain terminating at RPX/AST/LOT/Unified/OIN; this chain instead terminates at Verizon Patent and Licensing Inc., which is not a defensive aggregator. None of the five verdict labels fits cleanly: it is not an NPE (no shell transfer, no known asserter), not an "operating-company assertion" (no suit, and the terminal assignee does not itself ship products), and not a classic defensive-aggregator termination. I selected the closest category rather than force an NPE label. The one open field that could change this assessment is the per-recording correspondent (#3), which I could not retrieve; if manual inspection of the Assignment Center shows a repeat NPE-side recording attorney across the 2017–2021 links, that would warrant re-opening the NPE analysis.

Verification link: USPTO Assignment Search — https://assignment.uspto.gov/patent/index.html (and https://assignmentcenter.uspto.gov/) — search by patent number 8,024,290 / application 11/273,891. Pull the reel/frame and correspondent fields for all five recordings, which this analysis could not obtain from the available search results.

I'll research the prior art for US 8,024,290. Let me run targeted searches.

Let me dig deeper into the specific cited references on the face of the patent.

Note on search execution

I ran the requested USPTO-oriented searches for the literal number 8024290. My tooling returned the FreePatentsOnline "US Patent References" table and the Justia cited-references table for the record, but I was cut off by a tool step-limit before I could retrieve the complete "References Cited" section (backward citations), the Foreign Patent Documents list, and the "Other Publications" NPL list. What follows is therefore a partial but grounded reconstruction, with every item I could not independently verify explicitly flagged. I have not invented citations to fill the gap.

1. USPTO database result for "8024290" (literal)

• 8024290 → US 8,024,290 B2, "Data synchronization and device handling," App. No. 11/273,891, filed 2005-11-14, granted 2011-09-20, inventor of record Lie Yang et al. (Yahoo! Inc.). This is the patent under analysis and matches the record supplied in the prior sections.
• Excluded lookalikes (interpreted literally, not auto-corrected): JP 8024290 (Japanese publication), US 9,820,429 (John Deere/Precision Planting), the Brazilian municipal publication 8024290, and any corporate registration numbers. These are not the US patent.

Applicable law: because the application was filed 2005-11-14, pre-AIA 35 U.S.C. § 102 governs (post-AIA § 102 is inapplicable). This matters: pre-AIA § 102(e) gives a US patent/publication an effective prior-art date as of its US filing date, not its publication date, and requires the reference be "by another."

2. Provenance and completeness limitation of the citation list

Consequence: I can enumerate and analyze the references I retrieved, but I cannot certify that this is the complete 56-reference list as printed on the face of US 8,024,290. Completeness requires a fresh pull of the FPO/Justia page or the patent PDF.

3. The cited references, with dates and § 102 screening

Group A — Applicant's own Yahoo!/Yahoo-family US application publications

These were all filed in 2005 (mostly 2005-07-14 and 2005-10-28) — i.e., before the '290 filing date — and published in Jan./Feb./May 2007. Two of them are the applications expressly incorporated by reference into the '290 specification (identified in the Google Patents text as Ser. No. 11/182,287, filed 2005-07-14, and Ser. No. 11/264,121, filed 2005-10-31).

Critical caveat for this group: these are commonly owned Yahoo applications with overlapping inventors (Srinivasan, Boerries appear on both the '290 patent and several siblings). Pre-AIA § 102(e) requires the reference be "by another," which is satisfied only by a non-identical inventive entity; overlapping-inventor, commonly-owned material is weak § 102(e) art and is far better characterized as § 103 background or as admitted/incorporated subject matter. Note further that two of these are incorporated by reference into '290 itself, so they function as part of the '290 disclosure rather than as independent prior art.

Group B — Third-party US publications (sync/PIM art, 2001–2003 and 2006–2007)

(This Group B list reflects the Justia cited-references table for the '290 record; my retrieval truncated here. I have not verified the full text of each item, so each entry is a screening classification, not a verified anticipation finding.)

Group C — Issued US patents cited (system/device-management background)

Also cited (further entries on the FPO list that were truncated): additional US patents in the 2006 issue range — I could not retrieve them and will not guess.

Group D — Non-patent literature (NPL)

Confirmed from the specification text supplied (authoritative): US 8,024,290 itself describes and relies on the "SyncML Sync Protocol, version 1.1.1," dated October 2, 2002 (Open Mobile Alliance), with the URL http://www.openmobilealliance.org. This is an admitted prior-art specification and, because it predates the filing by more than one year, is available under pre-AIA § 102(b).

• Relevant to: claim elements (A), (B) (client/server synchronization sessions, client and server modifications, sync anchors), and the "slow sync" concept recited in dependent claims 5–6 and 15–16.
• Not anticipatory of claims 1/10/19: SyncML v1.1.1 describes two-party sync and slow-sync but does not disclose (i) the digest distinguishing user edits from device-characteristic edits, nor (ii) the local-first-then-query-remote-backend architecture with a second session/notice.

I could not verify the complete "Other Publications" list actually printed on the '290 face (my retrieval was truncated), so additional NPL citations may exist.

4. § 102 anticipation analysis — bottom line

No cited reference, on the record I was able to retrieve, anticipates independent claim 1, 10, or 19. The gating limitation is:

"determining … the client modifications based, at least in part, on a digest indicating which client modifications are changes by a user of the client device and which client modifications are changes due to characteristics of the client device" (claims 1, 10, 19).

None of the retrieved references (SyncML spec; Nokia/Samsung sync publications; the Yahoo content-router family; the device-management patents) is shown to disclose a digest keyed to device-imposed transformations — indexed, per the specification, by IMEI with per-entry LUID, and used to discriminate genuine user edits from device-caused changes. That element, combined with the local-inventory-first session followed by backend reconciliation, is what distinguishes the claims.

Consequently:

• Claims 1, 10, 19 — best attacked as § 103 combinations (e.g., SyncML v1.1.1 / US 2002/0161769 (Sutinen) / US 2003/0145021 (Parkkinen) for the sync-session elements, in view of a data-modulation/"shadow copy" reference for the digest element), not as § 102 anticipation.
• Claims 2–9, 11–18, 20–27 — dependent-claim features (second session; SMS/WAP-Push notification; LUID+CRC slow-sync optimization; device-capability modulation; empty sync/keep-alive) map to well-known art individually; the LUID/CRC slow-sync feature (claims 6, 16, 24) is the most vulnerable to a § 102 challenge if a reference is found that expressly does LUID+CRC inventory comparison.
• Most relevant single citation for § 102(e) purposes: US 2007/0016632 A1 ("System and method for synchronizing between a user device and a server in a communication network," Schulz et al., publ. Jan. 2007), a Yahoo sibling with a 2005 filing date — but it is commonly owned with overlapping inventors and topically familial, so it is weak § 102(e) art and better treated under § 103 / as incorporated disclosure.

5. Confidence and limitations (explicit)

• High confidence: identification of 8024290 as US 8,024,290 B2; the pre-AIA § 102 framework; the key point that the digest limitation is not met by the retrieved art; that US 2007/0088764 A1 (Yoon) has a post-'290 US filing date and therefore is not § 102(e) art.
• Moderate confidence: the per-reference subject-matter descriptions for the early-2000s publications — several are inferred from inventor/assignee and title and were not verified against full text.
• Low confidence / unverified: the completeness of the cited-reference list (both FPO and Justia tables were truncated in retrieval); the foreign patent documents section; the full "Other Publications" NPL list; exact publication day-months for the Yahoo sibling publications (I only have "January/February/May 2007" from FPO).
• Recommended next steps for a definitive § 102 study: pull the complete "References Cited" block and all NPL from the issued '290 PDF or the USPTO PatentCenter record (App. 11/273,891); confirm each reference's US filing date (not publication date) for § 102(e); and verify whether any non-identical-inventive-entity reference discloses the digest-based user-vs-device discrimination — the single element most likely to defeat a § 102 challenge.

No fabrication caveat: where I lacked the reference's content, I labeled it "not independently verified" rather than supplying a description.

I'll research the prior-art landscape for the '290 patent, including its cited references, the incorporated-by-reference Yahoo applications, and standards/art in the SyncML slow-sync space.

I have strong grounding on the slow-sync prior art and the incorporated-by-reference Yahoo "Content Router" family. Let me pin down a few more specifics: the IBM slow-sync publication (US 2005/0165947 A1), the examiner-cited references on the '290 face, and the related Yahoo synchronizing application.

Obviousness Analysis — US 8,024,290 B2 under 35 U.S.C. § 103

(Builds on the prior sections; no bibliographic or claim-listing content is repeated. Consistency check: the claim set, filing/priority dates, and the three independent claims (1, 10, 19) described earlier match the authoritative text — no contradictions found.)

1. Legal framework and timing

The '290 application was filed 2005-11-14, so it is governed by pre-AIA 35 U.S.C. §§ 102/103. Obviousness is assessed under Graham v. John Deere Co., 383 U.S. 1 (1966) with the flexibility of KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007): the question is whether the claimed subject matter as a whole would have been obvious to a person of ordinary skill at the time of invention, considering the scope and content of the prior art, the differences, the level of skill, and any objective indicia.

Two structural rules matter here:

• Pre-AIA § 103(c): subject matter that qualifies only as § 102(e)/(f)/(g) art — i.e., a published application or patent filed before the applicant's date — may not be used for obviousness if it and the claimed invention were commonly owned or subject to a common obligation of assignment. This is directly relevant to the Yahoo "Content Router" family (see §3, Ref C/D below), all filed 2005-07-14 and Yahoo-owned.
• Incorporation by reference: the '290 specification expressly states that the backend "includes a server and/or router as described in co-pending U.S. patent application Ser. Nos. 11/182,287 … and 11/264,121" — i.e., the Content Router applications. That is an admission that this two-tier architecture was known to the applicant at filing, usable as evidence of the state of the art even where the references themselves are §103(c)-shielded.

POSITA (proposed): as of November 2005, a person with a bachelor's degree in CS or EE and 2–4 years of experience building mobile client/server synchronization middleware, familiar with SyncML 1.1.x, HTTP/WSP/OBEX transports, PIM data models (contacts/calendar), and server-side change-logging. This is a modest skill level for a mature, standards-driven field.

Note this is not an AIA first-inventor-to-file case and not a Patent Act § 112 case; the analysis is purely § 102/103.

2. Prior art identified

Caveat (honest disclosure): My search of the '290 face returned only a partial examiner-cited list (e.g., US 2001/0047402 Saimi; US 2001/0049286 Hansmann; US 2002/0016818 Kirani; US 2003/0172139 Srinivasan et al. (a named '290 co-inventor); US 2003/0172175 and 2003/0172138 McCormack et al.) via justia/8024290#4. I could not fully characterize these in this pass, and the last two search steps were cut off, so the list below is not exhaustive of the prosecution record. The "Srinivasan et al." reference raises its own common-ownership question and should be verified before reliance.

3. Element-by-element mapping — claim 1

Claim 1 requires: (a) a server with data storage + processor; (b) a first sync session exchanging client/server modifications, server modifications based on locally stored sync data; (c) determining client modifications via a digest distinguishing user changes from device-characteristic changes; (d) in response to the first session, querying a remote backend database for differences between local and remote data; (e) exchanging further server modifications based on those differences.

Claim 10 and claim 19 are coextensive at the method and CRM levels, respectively (see prior section). They rise and fall with claim 1; claim 19's only additional wrinkle is "computer-readable storage medium … instructions tangibly stored thereon," which is not a substantively narrowing limitation for § 103 purposes here (the '290 CRM claim is drafted in ordinary non-transitory form; no Alice/§ 101 issue is presented by this task).

4. Primary combination: A + B (+ C as admitted architecture)

Proposed rejection: Claim 1 would have been obvious over SyncML 1.1.1 (A) in view of IBM US 2005/0165947 (B), further in view of the admitted Content-Router backend architecture (C).

Rationale and motivation to combine:

1. Same field, same problem, same solution family. All three references address SyncML client/server synchronization of PIM data. The '290 specification's stated problem is verbatim the problem IBM '947 states: field-by-field slow sync is "very inefficient because large amounts of unnecessary data … may be exchanged" (B) vs. the '290 spec's "expensive field-by-field slow sync analysis." When references "disclose a solution to the same problem," that is a classic KSR motivation. US20050165947A1

2. Express motivation in the art. The '290 Background itself recites: "If the connection is lost during the SyncML session, the client may need to perform a synchronization of all data … slow sync … may take an extended period of time leading to expensive data transfers." IBM '947 is a direct, contemporaneous answer to that exact concern. A POSITA reading the SyncML spec alongside IBM '947 would have been motivated to shorten/opt out of the field-by-field path.

3. The two-tier "local server + remote backend" split was admitted. The '290 applicant expressly points to the co-pending Content Router applications as the backend. A POSITA implementing '947's optimized flow on top of that admitted two-tier architecture — local sync/cache state and an authoritative backend account store — arrives at elements (a)/(b)/(d) without invention. This is "arranging old parts according to known methods" with predictable results (KSR). The deployed content-router family literally describes local command memory fronting remote user accounts and PIM applications, the same topology claim 1 recites.

4. Predictable result. Each element performs its known function. Serving the client from local state is standard proxy/cache design; reconciling to the authoritative store afterwards is standard two-phase/optimistic replication (cf. SyncML's own two-package structure and '947's "subsequent sync"). No new, unexpected result is produced.

Independent/de novo escape hatch: If the examiner resisted combining B for the slow-sync aspects, note that IBM '947 by itself also discloses a subsequent sync session (ops. 216–218) and a server-initiated slow sync request — directly supporting dependent claims 2/11/20, 3/12/21 and 5/15/23 even without the two-tier architecture.

5. Secondary combination for the dependent claims

Claim 6/16/24 deserves special emphasis because its entire inventive weight is "compare LUIDs and CRCs instead of field-by-field." The SyncML specification itself defines slow sync as field-by-field comparison ("the slow sync is a form of the two-way synchronization in which all items … are compared … on a field-by-field basis"), and IBM '947 was allowed because it replaced per-field comparison with summary data. Swapping "unique ID + timestamp" for "LUID + CRC" is a substitution of one known comparison key for another with no change in principle — textbook obviousness.

6. Strongest counterarguments (where the patent might survive)

Intellectual honesty requires flagging the soft spots; a real § 103 challenge would be decided on these:

1. The digest limitation (element (c)) is the only genuinely novel-looking feature. No reference I found teaches a server that uses a digest to affirmatively answer "is this client modification the user's edit, or an artifact of the device's characteristics?" The closest art (Content Router Repository, D) teaches store-and-restore of a stripped segment for data preservation, not for attribution of changes. But:

   • the "digest" idea is doubly encumbered — the best evidence (D, and C) is (i) Yahoo-common-owned, hence §103(c)-barred as §102(e) art, and (ii) merely incorporated by reference into '290 itself, so it functions as an admission of what the architecture looked like rather than as independent prior art;
   • and the remaining non-common art (SyncML B/E/F) teaches checksums and device profiles but not the attribution step.
   • Net effect: element (c) is the one limitation a challenger should expect to litigate. A combination that relies only on A+B+E+F for element (c) is weaker than one that can bring in D as prior art — and D may be off-limits for § 103.

2. "In response to the first synchronization session" (element (d)). IBM '947 keeps the server engaged through the sync; the '290 claim contemplates emitting the backend query as a consequence of the session (implying the session need not be held open). One could argue B teaches away by requiring the slow-sync to complete before the follow-on sync. However, SyncML's own two-package design and Busy Signaling let the server return status and resume later — so the "close first, reconcile after" sequence is not a departure from the art's grain.

3. Secondary considerations. There is no known evidence of record here of commercial success with nexus, long-felt need, or licensing attributable to the claims. The prior Litigation section found no enforcement, and the patent is Expired–Fee Related, which undercuts any "industry respect / copying" narrative. Objective indicia therefore do not appear to rebut an otherwise sound prima facie case (though absence of litigation is not itself evidence of obviousness).

4. Reliance caveat on the examination record. I could not obtain the complete "References Cited" list (search truncated), so it is possible the examiner already considered — and the applicant traversed — art more on point for element (c) than anything I have surfaced. I would not assert a § 103 conclusion on element (c) to a "high confidence" standard without that record.

7. Bottom line

• Claims 1, 10, 19 would have been obvious over SyncML 1.1.1 (A) + IBM US 2005/0165947 A1 (B), in view of the admitted Content-Router two-tier backend (C) — same field, same stated problem, express motivation to avoid field-by-field slow sync, and a purely predictable aggregation of known proxy/cache, two-phase-reconciliation, and summary-comparison techniques (KSR). The single limitation that meaningfully resists this combination is the digest-based discrimination of user edits vs. device-characteristic edits (claim 1 element (c)).
• Dependent claims 2–9 / 11–18 / 20–27 are each obvious over A + B, with A + B + E (checksums/CRC) for the LUID+CRC slow-sync claims (6/16/24), C + F (content-router gateway/UAWG profiles) for the device-modulation claims (7–8/17–18/25–26), and A (Busy Signaling) for the empty-sync claims (9/14/27).
• Applicability caveats: (i) pre-AIA § 103 controls; (ii) the Content Router family (C/D) is Yahoo-common-owned and therefore § 103(c)-shielded as § 102(e) art — use it as an admission of the architecture, not as stand-alone prior art; (iii) the '290 specification expressly disclaims the backends' novelty by incorporating them; (iv) the provenance and content of several examiner-cited references (including a "Srinivasan et al." reference) were not fully verified here.

Confidence: Moderate-to-high that the independent claims (especially claim 1's elements (a), (b), (d), (e)) are obvious over A+B(+C); moderate for element (c), pending review of the full prosecution record and any non-common-owner art that teaches change-attribution between user edits and device-imposed transformations.