US 8867894

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

Both initial searches returned empty. Let me try alternate query formulations.

I have good data on the patent itself. Now let me check specifically for 2026 CAFC docket activity and litigation history.

US Patent 8,867,894 B2 — Analysis

⚠️ Important caveat on the CAFC 2026 / USPTO docket search

I must be explicit about uncertainty here. I attempted multiple targeted searches for 2026 Court of Appeals for the Federal Circuit (CAFC) docket activity involving patent 8,867,894. No CAFC 2026 docket, appeal, or 2025–2026 litigation involving this patent was returned. My last three search queries were cut off by a search-step limit before returning results, so I cannot claim an exhaustive negative. What I can confirm from authoritative-style sources:

• The patent's recorded legal status is "Expired – Fee Related," with an anticipated expiration date of 2020-06-16 (per the Google Patents family/legal-status record).
• The only litigation surfaced by the Stanford NPE Litigation Database for this patent is 2015–2016 district-court activity, not appellate:
  1. YesVideo, Inc. v. iMemories, Inc., Case 2:15-cv-00809, E.D. Tex. (filed 2015)
  2. YesVideo Incorporated v. IMR16 Incorporated, Case 2:16-cv-00865, D. Ariz. (filed 2016)
  • Sources: Stanford NPE Litigation Database (npe.law.stanford.edu/patent/8867894) and Unified Patents litigation portal entries cited on the Google Patents page.

Given the 2020 expiration, a live 2026 CAFC merits appeal on this specific patent is unlikely — but I am flagging that I could not positively verify the absence of 2026 docket activity. Treat the "no 2026 CAFC docket" conclusion as unconfirmed, not authoritative.

---

Bibliographic Data

Note on inventor name: The Google Patents text renders the first inventor as "Sai-Wai Fu," while the granted-PDF OCR renders it "Sal-Wai Fu." I am treating "Sai-Wai Fu" as the literal entry and noting the OCR discrepancy rather than auto-correcting.

---

Abstract (verbatim)

"A method and apparatus for producing video content. The method includes acquiring video data from a source. If the video data is not digitized, then the video data is digitized. The method includes generating scene indexes for the video data including a representative still image for each scene and combining the video data and scene indexes along with a media player on a video disc. The video player is operable to play the video data in accordance with the scene indexes including playing a scene from the video data on a client computer while displaying the representative stills for other of the scenes available for display on the video disc."

Analyst note: The abstract describes a video-disc / media-player embodiment, but the issued independent claims are directed to a different (album-editing, edit-list, and distribution) subject matter. This is a common continuation phenomenon — the abstract carried over from the original 2000-era disclosure while the claims were prosecuted to different scope.

---

Plain-Language Overview of the Independent Claims (1, 13, 26)

Claim 1 — Client-side album authoring with server-side rendering

A method performed at a client device:

1. Identify a video content item to serve as the source for an "album" (the album = an edited version of that content).
2. Identify the segments in the video and a representative still for each segment.
3. Receive edit instructions over time from the user.
4. Receive an indication that editing is complete and the album should be finalized.
5. Generate an "edit list" capturing the edit instructions and send it to a server system.
6. Give the server access to the video content item.
7. Server edits the content per the edit list — notably including evaluating and generating NEW representative stills for segments that were trimmed.
8. Receive the user's instructions to distribute the edited album to distributees, and
9. Provide the server with distributee information so it can carry out distribution.

Plain English: You edit on your own computer, but instead of uploading/converting everything, you send the server a lightweight instruction list; the server re-renders the video and even refreshes the thumbnail images for clips you trimmed, then handles sending copies to the people you name.

Claim 13 — Server-side method keyed to a trim instruction

A method (server-centric) comprising:

1. Receive an identifier for a video content item that is the source for an album.
2. Receive an edit list of edit instructions, where at least one instruction is to trim a first segment.
3. Access the video content item.
4. Edit per the edit list, including evaluating and generating a new representative still for the first segment after trimming.
5. Receive the user's distribution instructions, and distribute the album to the distributees accordingly.

Plain English: The server-side counterpart of Claim 1, specifically requiring a trim operation and regeneration of the representative thumbnail for the trimmed clip before distribution.

Claim 26 — Cross-album recombining

A method comprising:

1. Identify multiple albums the user previously received from a central service, each album containing video data (edited scenes) and representative still image data per scene.
2. Receive the user's selection of scenes from at least two different albums.
3. Combine those selections into a NEW album (merging both the video data and the associated representative still data).
4. Receive an edit list with instructions, where at least one instruction is to trim a first [segment/scene] …
   • ⚠️ Uncertainty: The Claim 26 text available to me (via the RPX/Insight source) was truncated mid-sentence at the trim instruction. I do not have the full terminal limitations of Claim 26 and cannot confidently state its final steps. Do not rely on my Claim 26 summary beyond the four points above.

Claims 2–12 and 14–25 are dependent claims (dependent-claim text not reproduced here).

---

Summary of Reliability

• High confidence: bibliographic data, abstract, legal status ("Expired – Fee Related"), the 2015/2016 district-court cases, and the general scope of independent claims 1 and 13.
• Moderate confidence: Claim 26's full text (source was truncated).
• Low / unconfirmed: Whether any 2026 CAFC docket exists for this patent — I found none, but was unable to complete the full search suite before hitting a tool limit. A patent that expired on 2020-06-16 would be an unusual candidate for a live 2026 merits appeal, but I cannot rule out post-expiration appellate or collateral proceedings. Recommend re-running the CAFC docket check directly (e.g., CAFC PACER/CM-ECF or the CAFC "Opinions & Dockets" search) if 2026 appellate activity is material to your analysis.

I'll research litigation involving US 8,867,894 specifically.

Let me dig deeper into these two specific cases.

Let me get more specific case details from additional sources.

Litigation Involving U.S. Patent No. 8,867,894

I searched patent-litigation databases (Stanford NPE Litigation Database, Unified Patents litigation portal, Justia dockets, and CourtListener) using the exact number 8,867,894 only. Two district-court cases were asserted on this specific patent. Both were brought by the patent owner itself — YesVideo, Inc. (NPE Database classifies YesVideo as a "Practicing Entity" / "Product company," not a troll). Note also that Google Patents flags a "First worldwide family litigation" for this patent family.

---

Case 1 — YesVideo, Inc. v. iMemories, Inc.

Background: Per YesVideo's May 22, 2015 press release, the suit alleged that iMemories' online video editing/distribution services — including DVD production and sharing, promoted through Walgreens, Best Buy, Kodak, and The UPS Store — infringed the '894 patent. YesVideo sought an injunction and damages, and stated it had "not licensed it to any competitors." General Counsel Brian Knapp emphasized the patent's June 16, 2000 priority date.

Outcome: The docket shows the case was closed on March 29, 2016. Public docket summaries do not disclose the precise terminating instrument (e.g., voluntary dismissal, consent judgment, or settlement). Given that a related suit was filed against the same defendant shortly thereafter (Case 2 below), the March 2016 closure is consistent with a dismissal/settlement rather than a litigated judgment — but I could not confirm the specific terms from the available sources.

---

Case 2 — YesVideo, Inc. v. IMR16 Incorporated

Outcome: The case is recorded as closed on approximately August 10, 2016 — only about four months after filing. No judgment, damages award, or injunction appears in the available records. The very short pendency is consistent with an early dismissal or settlement, but as with Case 1, I could not verify the exact terminating document.

---

Summary / Caveats

• Total known litigation on U.S. 8,867,894: two cases, both plaintiff-side enforcement actions by the patent owner YesVideo, Inc. against the iMemories/IMR16 family of companies (2015 in E.D. Tex.; 2016 in D. Ariz.).
• Both are closed; neither produced a reported merits ruling in the sources I searched.
• Limitations on confidence: Docket metadata (case numbers, venues, filing dates, closure dates) is well corroborated across the Stanford NPE Database, Justia, and secondary docket mirrors. However, I could not independently confirm the precise reason for termination in either case (settlement vs. voluntary dismissal vs. other) — the available public summaries say only "Closed." Those specific outcomes should be verified against PACER/Unified Patents primary dockets before being relied upon.
• Watch out for confusion with unrelated "894"-suffixed patents that dominate search results (e.g., the AbbVie/AndroGel '894 patent in litigation against Teva and Perrigo, and the Solvay '894 patent). Those are different patents and are not related to U.S. 8,867,894.

Sources: Stanford NPE Litigation Database (patent page https://npe.law.stanford.edu/patent/8867894; case page https://npe.law.stanford.edu/case/[169192](/patent/169192)), Justia Dockets (D. Ariz. patent filings), YesVideo press release dated May 22, 2015 (WebWire), and docket summaries at ai-lab-cl-prod.azurewebsites.net for both cases.

I'll start by checking the structured record and then hunt for any AIA trial activity the ODP ingest may have missed.

The general search surfaced background but not trial numbers. Let me target the litigation parties and related patents.

Now let me check whether iMemories/IMR16 (or anyone else) petitioned the PTAB, and check the related continuation patent.

Proceedings overview

Total AIA trial proceedings on file for US 8,867,894: 0 (zero). The USPTO Open Data Portal structured block in my instructions is the canonical source and reports no IPR, PGR, or CBM proceeding ever instituted against this patent; my independent web searches for petitioner-side filings by the only known accused infringers (iMemories, Inc. / IMR16 Incorporated) and for any third-party petitioner likewise surfaced no petition, institution decision, FWD, or appeal naming US 8,867,894. Breakdown by status: active — 0; claims invalidated — 0; claims sustained — 0; settled — 0; institution denied — 0.

Bottom line for a defendant: there is no PTAB record either way — this patent was never stress-tested at the Board. It is not "hardened by surviving two IPRs"; it is untested and now expired, which is a materially different (and generally weaker) posture for the patent owner than a hardened patent. The absence of any IPR is explained largely by timing and economics: the '894 patent issued 2014-10-21, was asserted only against a small competitor in 2015–2016, and reached its anticipated expiration on 2020-06-16, with the record showing "Expired - Fee Related" status. A troll asserting it today would be asserting an expired patent with a closed damages window.

⚠️ Search false positive to flag and disregard. A web hit returned a PTAB petition paper referring to an "'894" patent with SNMP/CGI limitations, a 1995-11-13 priority date, parents '178/'500/'556/'158 and provisional 60/006,634, opposed by SAP. That is a different patent (different field, different priority date, different family). Do not attribute that record to US 8,867,894. I found nothing linking that paper to this video-processing patent.

---

Proceeding-by-proceeding

None. There are no AIA trial proceedings to walk through.

For completeness on what does exist in the public record (litigation, not PTAB — provided only so you don't mistake it for trial activity):

• YesVideo, Inc. v. iMemories, Inc., No. 2:15-cv-00809 (E.D. Tex.), filed 2015-05-21, asserting the '894 patent. Docket status: Closed (2016-03-29). The termination terms were not disclosed in the sources I could reach; I will not characterize it as a settlement, dismissal, or judgment.
  • Docket reference: https://ai-lab-cl-prod.azurewebsites.net/case/dct/txed/2:15-cv-00809/yesvideo-inc-v-imemories-inc
  • NPE litigation record: https://npe.law.stanford.edu/patent/[8867894](/patent/8867894)
• YesVideo Incorporated v. IMR16 Incorporated, No. 2:16-cv-00865 (D. Ariz.) — the Arizona case flagged in the patent's litigation block (https://portal.unifiedpatents.com/litigation/Arizona%20District%20Court/case/2%3A16-cv-00865). No PTAB record is associated with it.
• Press release confirming the assertion theory and the patent's 2000-06-16 priority: https://www.webwire.com/ViewPressRel.asp?aId=[197866](/patent/197866)

---

Strategic summary

Claim status. Independent claims stand as issued. Because no AIA trial ever reached a Final Written Decision, no claim of US 8,867,894 has been canceled, disclaimed, or held unpatentable by the PTAB, and — equally — no claim has been sustained by the PTAB either. Every claim is legally UNTESTED at the Board. Do not let anyone tell you a claim is "confirmed" or "hardened." The only narrowing signal in the record is the ordinary prosecution history, not a trial outcome.

Expiration is the dominant fact. The face of the patent shows an anticipated expiration of 2020-06-16 (20 years from the 2000-06-16 priority date) and a current legal status of Expired - Fee Related. Practically, that means: (a) no infringing acts can occur after mid-2020, so the damages exposure is historical only; (b) the § 286 six-year lookback from any realistic 2026 filing date now reaches back only to 2020, which sits at or after the expiration boundary — i.e., there is effectively no recoverable infringement window left; and (c) any demand letter citing ongoing infringement is built on a patent that is no longer in force.

Estoppel landscape — § 315(e)(2) is a non-issue. Because no IPR was ever instituted or terminated by FWD, there is no IPR estoppel binding anyone. No petitioner is estopped, and no defendant inherits a bar from a privy's earlier petition. Every § 102/§ 103 ground — including art that would have been foreseeable in 2015–2016 — remains nominally available in an invalidity defense, subject only to district-court constraints (Therasense/IDS duties, IPR-era timing) and to the fact that the patent's term has run. Note the asymmetry: the flip side of "no estoppel" is also "no free kill" — you cannot shortcut to a PTAB certificate of cancellation, and an IPR on an expired patent is a hard sell at the Board absent a live (e.g., past-damages) controversy.

Pattern signals. No recurring petitioner, no serial IPR filer, and no defensive aggregator (e.g., Unified Patents) in the chain — Unified's database surfaces this patent only as a district-court litigation record, not as an IPR party. The patent owner (YesVideo, Inc.) has never pursued a PTAB appeal because it never lost at the PTAB. The litigation posture was a single operating company suing a single competitor (2015–2016), not a broad assertion campaign — which is precisely why the patent never attracted the IPR attention that well-asserted patents eventually do. The one family data point worth checking before you rely on it: the patent record cross-references US 9,390,755 ("priority to US14/518,989", 2014-10-20), a continuation in the same family. I did not verify its claims, status, or expiration — confirm separately, though it shares the same 2000-06-16 priority chain and would face the same term calculus.

---

Recommended next steps

1. If you are a defendant receiving a demand or complaint citing US 8,867,894: lead with expiration. Cite the patent's own front page — anticipated expiration 2020-06-16, status Expired - Fee Related — and the statutory bar in 35 U.S.C. § 271(a) (no "making, using, offering to sell, or selling within the United States" after that date) plus the § 286 six-year damages lookback. There is no FWD to link to here, because none exists; your argument is a term/status argument, not an invalidity-victory argument.
2. If the assertion is ongoing conduct: insist on claim charts identifying specific post-2020 acts. There should be none that are actionable.
3. If you nevertheless want an invalidity posture: run your own prior-art search against the 2000-06-16 priority and the prosecution history. Do not assume past IPR art exists to borrow — it doesn't. Also evaluate whether the asserted claims are even entitled to the 2000-06-16 priority (a written-description/enablement attack could move the date later, but toward 2013, not earlier).
4. Before relying on the '755 family member: pull its file wrapper and maintenance-fee status directly. If it shares the 2000-06-16 priority, it is likely expired as well, but I have not confirmed that.
5. If you need a PTAB option anyway: note that an IPR on an expired patent is not categorically unavailable, but institution is discretionary and fact-dependent, and the Board's incentive to institute on a patent with no forward-looking exclusionary effect is low. Treat it as a fallback, not the plan.
6. Preservation: the E.D. Tex. case closed 2016-03-29 and the Arizona case (2:16-cv-00865) docket terms are not reflected in what I could retrieve. If the patent owner now claims issue preclusion, license, or a covenant based on either case, pull the full dockets — the public sources I reached do not state the disposition terms, and I am not going to guess at them.

Confidence note: I am highly confident there is no PTAB proceeding on this patent, based on (a) the canonical ODP block stating no AIA trials and (b) my searches of the parties most likely to have filed. I am not confident about the disposition terms of the two district-court cases, and I have not verified the status of US 9,390,755.

I'll research the assignment chain, litigation history, and corporate status before writing the report.

Now let me dig for the recorded assignment data and post-issuance ownership events.

Assignment & Ownership Analysis — US 8,867,894 B2 ("Video Processing System")

Verification note (read first): The authoritative full text of this patent was provided and is the primary source for dates, inventors, and assignee. Google Patents' legal-events pane for US 8,867,894 exposes exactly one post-filing reassignment record (2013‑08‑15, inventors → YesVideo, Inc.). That record as surfaced does not display a reel/frame number, and I could not retrieve reel/frame data directly from Assignment Center within this session. I therefore report the single recorded conveyance with its date and parties, and flag reel/frame as not exposed / not verified. I have not invented reel/frame numbers.

---

Inventors

All six named inventors are the original 2000‑era development team for the present invention (priority date 2000‑06‑16). The application that issued as the '894 patent (Ser. No. 13/919,825) was filed 2013‑06‑17 as a later continuation in the YesVideo family — the 13‑year gap between priority and filing is the reason a fresh inventor→company assignment had to be executed in 2013, even though the inventors had long since assigned the original 2000 application.

Pattern note: There is no indication of inventors departing the assignee within 12 months of filing. The assignment data shows the inventors transferring to YesVideo, not away from it. This is the opposite of the pre‑fire‑sale pattern. (I did not find a corroborated record of any inventor's individual departure date, so I state this as "no contrary evidence found," not as a verified fact.)

---

Original assignee

YesVideo, Inc., Santa Clara, CA — the entity named on the issued face of the patent ((71) Applicant: YesVideo, Inc., Santa Clara, CA (US); (73) Assignee).

• Products embodying the claims: Yes — YesVideo is a consumer/professional media digitization and cloud video service: it digitizes home movie tapes/film, hosts them for online editing, and ships DVDs/physical media and digital deliverables. That is precisely the practice described in the '894 claims (scene indexes, representative stills, media player burned to disc). The company's own 2015 press release describes it as "the largest and most trusted family movies digitization and online cloud service worldwide," offering "online editing and ordering tools for the customers of our retail partners."
• Primary line of business: Consumer video transfer/digitization and a cloud video editing, storage, and distribution platform, sold through retail partners (Walgreens, Best Buy, Kodak, The UPS Store, Costco/CVS-type channels).
• Current status: Reported private and venture‑backed, founded 1999, and still listed as an operating company (PitchBook profile shows a 67‑employee private company with later‑stage VC rounds in 2012/2016 and secondary transactions in 2016 and 2021, plus a 2020 PPP loan). I did not find a primary‑source (SEC or state registry) confirmation of current operating status, so treat "still operating" as reported, not verified. No bankruptcy filing surfaced in any search. The patent itself went Expired – Fee Related at the 2020‑06‑16 maintenance deadline, meaning the asserted asset was allowed to lapse ~5 years after the litigation campaign.

---

Assignment timeline

1. 2013‑08‑15 (executed) / recorded 2013‑08‑15 — Reel/Frame: not exposed in accessible sources (not verified)

• Conveyance: Assignment (ASSIGNMENT OF ASSIGNORS INTEREST — see document for details)
• Assignor: Ahmad, Subutai; Edwards, Jeffrey Layne; Fu, Sai‑Wai; Honey, Sadie Louise; Sit, Hon Pun; Ullal, Adwait (all six named inventors)
• Assignee: YESVIDEO, INC.
• Correspondent: Not determinable from the sources accessible to me. The prosecution agent of record for this application is Fish & Richardson P.C. (per PatentGuru assignee/prosecution data) — that is the patent‑prosecution firm, not confirmed to be the assignment‑recording correspondent. I am not treating a single, unconfirmed appearance as a repeat‑correspondent finding.
• Context: Housekeeping / chain‑of‑title confirmation. This is an inventor‑to‑company assignment executed contemporaneously with the 2013‑06‑17 filing of continuation Ser. No. 13/919,825, confirming the 2000‑era team's transfer of rights in the new application. It is not a transfer to a third party, not a securitization, and not a liquidation.

That is the only recorded assignment on this patent. No post‑issuance assignment to any IP‑holding LLC, no security interest, no merger, no release, and no transfer to an aggregator or asserter appears in the record. YesVideo, Inc. remained the owner of record through issuance (2014‑10‑21) and through both infringement suits.

(Related family activity for context, not a '894 assignment: a continuation filed 2014‑10‑20 as Ser. No. 14/518,989 issued as US 9,390,755 B2. Family members include US 6,721,361 B1 and US 7,668,438 B2, and EP 1 074 989 / DE 60143663D1 from the 2000‑06‑14/16 filing. An apparent "Yesvideo.Com, A Corporation" assignee string appears in family‑level legal events around 2006‑09‑07, which is consistent with a change of name (Yesvideo.Com → YesVideo, Inc.) on earlier family members — I flag this as unverified for the '894 patent specifically.)

---

Timeline diagram

timeline
    title Ownership of US 8867894
    2000 : Priority date for invention
    2013 : Continuation filed by YesVideo Inc
         : Inventors assign rights to YesVideo Inc
    2014 : Patent issued to YesVideo Inc
    2015 : YesVideo sues iMemories in E D Texas
    2016 : YesVideo sues iMemories in Arizona
    2020 : Patent expires for unpaid fees

---

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT. The only recorded conveyance runs from the six named inventors to YesVideo, Inc., the operating company itself (Google Patents legal events, 2013‑08‑15; assignee of record on the issued patent). There is no "IP / Patents / Licensing / Holdings / Ventures" entity anywhere in the chain, no registered‑agent address, and no single‑purpose LLC.

2. Known asserter in the chain — NOT PRESENT. YesVideo, Inc. does not appear on any of the referenced NPE lists (Acacia, Marathon, IV, IPNav, Wi‑LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, DGC, Spangenberg entities). Independent third‑party classification cuts the other way: the Stanford NPE Litigation Database classifies YesVideo as a "Product company" (Asserter Category 8) on the very cases asserting this patent.

3. Repeat correspondent across the chain — NOT PRESENT / UNCLEAR. With only one recorded assignment in the chain, there is no recurrence to detect. The only firm associated with the matter is Fish & Richardson P.C. as prosecution agent, which does not satisfy the stated test ("the signal is recurrence"). Unverified and therefore not a finding.

4. Cascading transfers — NOT PRESENT. A single assignment (2013‑08‑15) followed by no further transfers. No chained LLCs, no shared correspondent addresses, no common‑principal shells, and certainly nothing within 24 months.

5. Pre‑litigation transfer — NOT PRESENT. The assignment executed 2013‑08‑15; the first suit naming this patent was filed 2015‑05‑21 (YesVideo, Inc. v. iMemories, Inc., 2:15‑cv‑00809, E.D. Tex.). That is a ~21‑month gap, and the assignment predates the patent's own issuance (2014‑10‑21). The chain was not arranged to set venue or manufacture standing — YesVideo asserted its own patent in its own name.

6. Bankruptcy fire‑sale — NOT PRESENT. No Chapter 7/11 proceeding involving YesVideo surfaced. YesVideo was still transacting (acquired Yarly, Inc. in 2015; raised later‑stage VC in 2016; secondary transactions in 2016 and 2021) around and after the litigation. The patent lapsed for unpaid maintenance fees in 2020 — an abandonment, not a distressed sale.

7. Privateering — NOT PRESENT. YesVideo did not transfer the patent to a third‑party assertion vehicle. It sued directly and in its own name as the operating company, seeking an injunction and damages against a direct competitor. Its General Counsel, Brian Knapp, publicly framed the suit as protecting an in‑house investment ("YesVideo has not licensed it to any competitors"). That is classic operating‑company assertion, the inverse of privateering.

8. Defensive aggregator — NOT PRESENT. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. It terminates in the original operating assignee, and then in expiration.

---

Verdict

Operating-company assertion — the stronger of the two non‑NPE categories here, and supported by direct evidence.

The full chain is a single inventor→company assignment to YesVideo, Inc. (2013‑08‑15), with no subsequent transfer of any kind; the company is the assignee of record on the issued patent and sued in its own name against two affiliates in the same competitor group — 2:15‑cv‑00809 (E.D. Tex., filed 2015‑05‑21) and 2:16‑cv‑00865 (D. Ariz., filed 2016‑03‑30) — seeking injunctive relief for alleged infringement of the '894 claims by iMemories/IMR16, whose online video‑editing‑and‑disc‑distribution service practises the claimed subject matter. YesVideo ships a commercial product and service embodying the claims (retail tape digitization, cloud editing, DVD output), which is why the Stanford NPE Litigation Database scores this asserter as a "Product company" — and the ~21‑month gap between the assignment and the first suit defeats any pre‑litigation‑transfer inference. The only event that would push this toward an NPE characterization is absent: there is no shell‑entity transfer, no known asserter, and no aggregator anywhere in the record.

Practical bottom line: this is a practising‑entity patent that was asserted twice and then abandoned to lapse at the 2020‑06‑16 fee deadline (status: Expired – Fee Related), so the asset is currently unenforceable by anyone.

Verify at: https://assignmentcenter.uspto.gov/ (search "8867894") and https://assignment.uspto.gov/patent/index.html — request the reel/frame for the single 2013‑08‑15 YesVideo record and for any security‑interest filings that may not be surfaced by Google Patents.

Confidence caveat: the patent text and Google Patents legal events are treated as authoritative and reported literally. The reel/frame, the recording correspondent's identity, and YesVideo's present‑day corporate status are the three items I could not verify from primary sources in this session and I have marked them as such rather than inferring them.

I'll research US patent 8,867,894 and its cited prior art.

Let me get the specific citation sections from the patent record.

Let me find the "Patent Citations" (references cited) section specifically.

Bottom line up front

I could not retrieve the actual front‑page "References Cited" / "Patent Citations" list for US 8,867,894 in this session, and the authoritative full text I was given for the patent does not include it (nor does it include the claims). Under my operating rules I will not fabricate a citation list or § 102 mappings. Below is (A) what the patent record reliably shows, (B) the references that did surface in the citation tables during my searches — clearly labeled by their actual role — and (C) what I can and cannot say about § 102. I flag the one data point that is uncertain.

---

A. Patent identification (verified from the authoritative full text)

Note the important posture: this is a 2013‑filed continuation with a 2000‑06‑16 priority claim. Any reference dated after 2000‑06‑16 can only matter if the asserted claim is denied that priority date (e.g., lack of § 112 written‑description support for new matter).

Claim scope (inferred only from the printed Abstract/Summary, since the claim text was not supplied): acquiring video data, digitizing if needed, generating scene indexes each with a representative still, and combining video data + scene indexes + a media player on a video disc, the player operable to play a scene while displaying stills of the other scenes.

---

B. References that surfaced in the citation tables — labeled by actual role

B1. Same‑family / self documents (NOT prior art)

• US 9,390,755 B2 — YesVideo, Inc.; app. 14/518,989; priority 2000‑06‑16; granted 2016‑07‑12. Continuation of the same family.
• US 2013/0294750 A1 — pre‑grant publication of US 8,867,894 itself.
• EP 1,074,989 A2/A3 — "Video data conversion mechanism," the European family member.

B2. Candidate prior‑art references (predate or surround the 2000‑06‑16 priority date)

These appeared in the patent family's citation tables and bear earlier dates, which is the signature of backward (prior‑art) citations — but I could not verify which are examiner‑cited vs. applicant‑cited, nor confirm they sit on the face of US 8,867,894 specifically vs. a sibling:

B3. Forward citations (later patents citing this one — NOT prior art)

• US 2010/0100598 A1 — Kabushiki Kaisha Toshiba — terminal data transmission.
• US 9,082,092 B1 — Google Inc. — "Interactive digital media items with multiple storylines."

---

C. On the § 102 mapping you requested

I cannot responsibly complete a claim‑by‑claim § 102 anticipation analysis, for two concrete reasons:

1. The claim text of US 8,867,894 was not in the material provided to me (only the Abstract, Summary, and Description were supplied), so I have no claim language to map references against.
2. The verified face‑of‑patent citation list was not retrievable in my searches, so I cannot assert which references are in fact cited against this patent.

What I can say directionally (low confidence, and explicitly not a legal conclusion):

• The broadest independent claim, as reflected in the Abstract, is a disc‑authoring plus scene‑navigation claim. Thematically, US 6,859,799 (Gemstar) and US 7,788,686 (Andrews) are the closest functional analogs for the scene‑index / thumbnail / navigation aspects; US 6,845,448 / US 8,117,644 (Pennar) touch the online repository / album hosting aspects. Any of these would be the candidates one would test first for anticipation of a broad claim — assuming they are actually cited references, which I have not confirmed.

---

Recommended verification step

To get the exact, literal list the search request requires, pull the "Patent Citations" table from the Google Patents page (patents.google.com/patent/US8867894B2) or the "References Cited" section on USPTO Patent Center / Global Dossier for application 13/919,825. Those tables distinguish examiner‑cited from applicant‑cited art, which is precisely the field you asked me to enumerate. If you paste that list here, I will produce the full citation / date / description / § 102 claim‑mapping table you specified.

I want to be explicit rather than fill the gap with plausible‑looking patent numbers: I do not currently know, with high confidence, the exact "References Cited" list for US 8,867,894, and I have marked every item above with its actual evidentiary role.

I'll first try to retrieve the actual prior-art citations listed for this patent, since the page text provided to me does not include the "References Cited" / "Cited By" list — a gap I need to flag or fill.

The PDF search returned a partial "References Cited" list. Let me try to retrieve the complete list (both the U.S. patents and the "Cited By" entries).

Let me verify the identities and dates of the most analytically important cited references.

I hit the search-step limit mid-verification. Here is the § 103 analysis with explicit flags about what I could and could not verify.

---

Obviousness Analysis — U.S. Patent No. 8,867,894 B2 ("Video processing system")

0. Scope, sources, and mandatory caveats

⚠️ Caveat 1 — the "Prior Art" section of the fetched page is not in the text I was given.
The page text supplied to me contains Prior art keywords ("album, video, user, scene, instructions") and the Classifications and Landscapes sections, but it does not contain the "Patent Citations / Cited By / References Cited" tables. Nothing appears between "Landscapes" and "Abstract." I therefore could not "use the results from the Prior Art section of this page" as instructed in the literal sense. Instead I reconstructed the face-of-the-patent prior art from the granted-PDF "References Cited" block via search (source: https://patentimages.storage.googleapis.com/d1/d7/bb/62d859dcaeeb4c/US8867894.pdf). That reconstruction is partial — the citation list was truncated in the returned snippet at "6,27…" — and it is OCR-degraded (e.g., "Wachter" renders cleanly, but "Ohtsena, Jr.", "Trevitti", "Yaqoshif" and "Asile" are garbled). Per my operating rules I am not auto-correcting those identifiers.

⚠️ Caveat 2 — I do not have the '894 file wrapper. I cannot tell which cited references were actually applied in an Examiner rejection (i.e., true art-of-record) versus merely listed in an applicant IDS. This matters enormously: many of the entries below are classic scene-detection/librarian references that look like IDS material for a 2000-priority software case.

⚠️ Caveat 3 — verification level is mixed. Only two references could be positively re-verified in this session (US 5,835,667 and the family/other-publication items). Titles and dates for most other references are as printed in the OCR'd patent front page and I flag my confidence per row. I did not fabricate any title.

⚠️ Caveat 4 — priority-date anomaly. Two cited foreign documents are dated after the June 16, 2000 priority date: EP 1 074 989 (Feb. 2001) and EP 1 154 432 (Nov. 2001). As published European applications they cannot be § 102(a)/(b) art against a 2000 priority date (and EP publications do not generally qualify for § 102(e)). This is either (a) an IDS listing, (b) art cited against claims that the Examiner/applicant treated as not entitled to the 2000 priority date, or (c) OCR noise. I cannot resolve this without the file history and I flag it as a live issue rather than papering over it — see § 7.3, because it cuts to a real invalidity theory.

Relationship to the earlier-generated sections. This analysis builds on — and does not repeat — the claim summaries already produced. Two cross-references:

• The earlier section noted that the Abstract describes a video-disc/media-player embodiment while the issued independent claims are directed to album-editing, edit-list and distribution subject matter. That mismatch is directly relevant here: the Abstract/2000 disclosure is where the prior art of record is concentrated (scene detection, rep-frame extraction, video discs), whereas the independent claims are directed to networked edit-list authoring and re-rendering. That gap is the central obviousness battleground (§ 7.3).
• The earlier section flagged Claim 26 as truncated. Consistent with that, my Claim 26 analysis below is expressly limited to its four verified elements.

---

1. The decisive limitations

Stripping the claims to what actually drives patentability:

The Google-generated "Prior art keywords" for this patent are album, video, user, scene, instructions — consistent with the above: the claimed contribution is an album workflow, not a new segmentation or encoding technique.

---

2. Prior art of record (as reconstructed)

Not of record but highly material (candidate art for an IPR/PGR-style attack, flagged as unverified in this session): US 5,708,767 and US 5,821,945 (Princeton, "Method and apparatus for video browsing based on content and structure"); industry-standard Edit Decision List (EDL) practice (CMX-format EDLs, in commercial use since the 1970s); and consumer NLE software available pre-June-2000 such as Apple iMovie (Oct. 1999), which already performed client-side clip trimming with per-clip thumbnail frames.

---

3. Element mapping for the independent claims

---

4. Combination 1 — the primary obviousness case (claims 1 and 13)

Wachter '667 + Zabih '922 (or Zhang '982) + Rangan '751 (or Taniguchi '294), optionally + earthnoise.com.

Why each is placed:

• Wachter '667 discloses exactly the L1 architecture in a networked setting: a digitized video library in which content is automatically partitioned into segments, each segment carries representative/key frame imagery, and users retrieve and assemble material from that library. It supplies L1 and much of L5 (a library holding many video documents is, in substance, "scenes from more than one album").
• Zabih '922 / Zhang '982 supply the specific segmentation mechanism (color-histogram and motion/pixel-difference transition detection with thresholds) that the '894 specification describes at length — see the spec's own color-difference formula CD = Σ min(H₁,H₂)/N and motion difference MD = Σm(x,y), both of which are textbook histogram-intersection / pixel-difference techniques of the kind Zabih and Zhang disclose.
• Rangan '751 / Taniguchi '294 supply the distributed authoring-then-server-render architecture: a client constructs a description of desired content, and a remote system assembles and delivers the media to designated recipients.
• earthnoose/earthnoise.com supplies the commercial pattern of a consumer uploading home video to a hosted service, having it indexed, editing it in a browser, and sharing it with others by e-mail/web — i.e., L2's client/server split and L4's distribution.

Motivation to combine (KSR factors):

1. Same field, same problem, same solution-shape. All four address organizing consumer/non-professional video for retrieval, editing and delivery. Wachter's stated purpose (making an unmanageable video corpus searchable and reusable) is the '894 Background's stated problem (tapes degrade; users over-record junk and never edit it).
2. Predictable result / mere aggregation. Combining a known segmentation method with a known library and a known client/server delivery channel produces no more than the expected result — an indexed, editable, deliverable video. KSR Int'l v. Teleflex, 550 U.S. 398, 416 (2007) ("the combination of familiar elements according to known methods is likely to be obvious when it does no more than yield predictable results").
3. Market pressure. The '894 Background itself documents the demand-side pressure: tape-to-tape duplication is available but costly, and professional tape-to-optical-disk encoding runs "on the order of magnitude of $60/min." That price point is a textbook "design incentive" and "market force" rationale for moving the editing decisions to the client and the heavy rendering to a server.
4. The very architecture is implied by bandwidth economics. Keeping high-resolution content server-side and transmitting only a lightweight instruction file is the obvious engineering response to late-1990s consumer bandwidth. This is the § 103 rationale the applicant's own specification celebrates ("Each edit list can define a set of operations … so as to allow editing operations defined on one computer to be performed on the video data to be replicated on another computer").
5. No teaching away. Nothing in Wachter, Zabih/Zhang, Rangan/Taniguchi or earthnoise.com teaches away from client-side decision-making with server-side rendering.

Weakness of this combination (be candid): Combination 1 maps L1, L2 and L4 cleanly. It does not, on its own, disclose L3's "new representative still generated for the trimmed segment." That requires Combination 2.

---

5. Combination 2 — the narrow limitation (L3): trim-triggered still regeneration

Combination 1 + Tonomura '950 (or Nagasaka '439/'218, Hibi '191, Kubota '434), combined with the EDL/edit-list execution teachings of Rangan '751 or Kelly '292.

The reasoning:

1. The rep-frame references teach the general rule that a segment's representative frame should be a frame that best represents that segment's content (e.g., Nagasaka/Hibi/Kubota selecting a frame by color-distribution similarity to the segment as a whole — precisely the "segment intro / average-histogram best match" technique recited in the '894 specification).
2. An edit list containing a trim instruction changes the segment. A person of ordinary skill implementing an edit list therefore faces an immediate, recognized consequence: the previously stored still is now derived from frames that the user has deleted, so it no longer represents the segment.
3. Re-running the same, already-known rep-frame selection routine over the post-trim segment is a simple substitution of a smaller input range into a known algorithm — a predictable variation with no unexpected result. KSR, 550 U.S. at 417 (obvious to try where there is "a finite number of identified, predictable solutions").
4. The patent itself treats this as bookkeeping, not invention. The specification's publication workflow states: "Steps to be completed include extracting new stills for any trimmed scenes, creation of a customized title screen, creation of a final streaming version of the album … and the creation of the final high resolution version of the storyboard." The applicant enumerated it in a comma-delimited list of routine post-publication housekeeping steps. That listing is powerful evidence that the step was regarded as conventional, and it is available as an admission about the state of the art.
5. Design incentive / user-experience motivation. Any UI that displays thumbnails for distributable clips (as both Wachter and the '894's own Fig. 5b edit page do) is motivated to keep thumbnails synchronized with content — a stale-thumbnail is a defect, and correcting it is the obvious quality-control fix. (Note the '894 specification's own quality-control theme: the content monitoring module, bad-video-segment detection, regression analysis on a database of home camcorder footage.)

Practical significance: L3 is the limitation most likely to survive an obviousness challenge, but only if the patentee can show (a) the prior art did not suggest re-deriving stills when the segment changed, and (b) the "evaluate → generate new still" step is not merely the known rep-frame routine re-run on a known-shorter clip. Given point 4, that showing is difficult. A secondary reference that expressly ties derived metadata to the edited version of a clip (e.g., a content-management/post-production reference such as "Trevitti" '531 or Vigneaux '435, both of record) would close the gap further.

---

6. Combination 3 — Claim 26 (cross-album recombination)

Wachter '667 + Rangan '751 + Tonomura '950 (optionally the '894 family's own earlier applications, see § 7.3).

• "A plurality of albums previously received from a central service, each containing video data and representative still image data per scene." Wachter '667's library returns, to a client, discrete indexed video documents each with associated key frames; transferred to a user (as earthnoise.com teaches for consumer video), the user holds exactly this plural-album corpus.
• "Selecting scenes from at least two different albums." Wachter's browsing interface is a corpus-level interface: selecting items across multiple source documents into a new presentation is its core function. Tonomura '950's "video icon" abstraction teaches recombination of segments from multiple sources into a new presentation.
• "Combining into a new album (merging video + representative still data)." Rangan '751's personal-media-library/"jukebox" model teaches assembling a new playlist/composition from previously stored items while carrying their index imagery.
• Motivation: Recombining material across previously created compilations is the whole point of maintaining a video library — a "collection" view. The '894 specification's own edit page (Fig. 5e/5f, collection frame 570 feeding clip frame 554) describes exactly this as a feature, without describing any new mechanism. Non-obviousness argument available to the patentee: none strong; the combination is the aggregation of known functions with predictable results.

Confidence note: Because Claim 26's terminal limitations remain unavailable to me (per the earlier section and the truncated source), I cannot state whether Claim 26 adds a further, non-obvious step after the trim instruction. If Claim 26 terminates in the same "generate a new representative still after trim" limitation as Claims 1/13, then § 5's reasoning applies. This must be resolved against the granted claim text before relying on this section.

---

7. Additional theories and a caution

7.1 Industry-standard practice (EDLs) as § 103 art in its own right

An Edit Decision List — a plain-text list of source timecodes and edit operations transmitted from an offline workstation to an online finishing system for conformance — has been standard in video post-production since the CMX-format era. The '894's independent claims' "edit list … so as to allow editing operations defined on one computer to be performed on the video data to be replicated on another computer" reads on this practice almost verbatim. Combined with any client/server delivery reference, this is a strong "known technique applied to a known device ready for improvement" rationale. (I flag: I did not re-verify an EDL reference in this session; treat as a lead to be documented.)

7.2 Consumer NLE software

Apple iMovie (released October 1999) performed client-side trimming of clips and displayed per-clip thumbnail frames. If a pre-June-2000 product manually, brochure or review is used as art, it supplies L2 and the client-side half of L3's purpose. (Unverified in this session — recommend corroboration before use.)

7.3 The priority-dependence attack (flagged, and it is genuinely important)

Two of the references of record are dated after the June 16, 2000 priority date (EP 1 074 989, 02/2001; EP 1 154 432, 11/2001). Separately, the family includes US 6,882,793 B1 (priority 2000-06-16) and US 6,721,361 B1 (filed 2001-02-23) — both "Video processing system," both YesVideo.Com/YesVideo (confirmed via Google Patents citation records). These are family members, not art, if and only if the '894 claims are entitled to the 2000 priority date.

But the earlier-generated section of this analysis records that the Abstract/2000 disclosure is about video discs and media players, while the issued claims are about networked album editing, edit lists, and distribution. If the asserted claims of the '894 lack written-description support in the 2000 application (i.e., they rest on matter added in the 2010 continuation 12/683,370 or in the 2013 filing), then:

• the effective filing date of those claims is 2010 or 2013, and
• the entire intervening decade becomes prior art — including the family's own earlier-published applications (US 6,882,793, published 2005; US 6,721,361, published 2004) and the two EP documents that otherwise look anomalous.

This would be a § 102/§ 103 knockout rather than a close § 103 case, and it plausibly explains why post-2000 EP documents were cited at all. I am deliberately not asserting that the claims lack support — I do not have the 2000 application's text or the '894 file wrapper. I flag it because it is the single highest-leverage issue in this analysis and it is checkable against primary sources (the 09/595,615-era specification and the '894 prosecution history).

7.4 Caution — do not over-claim on Claim 26

The earlier section correctly flagged that Claim 26's text was truncated. Do not build a validity opinion on my § 6 mapping until the full claim text is obtained.

7.5 Not addressed here

This is a § 103 analysis only. The independent claims recite generic client/server hardware and otherwise-abstract album workflow steps; a § 101 challenge (as in Alice/Mayo) is a separate and, given the 2014 patent's unremarkable hardware recitations, arguably more dangerous line of attack. Flagging, not analyzing.

---

8. What the patentee would argue, and the responses

---

9. Bottom line

The pivot point is one limitation: "evaluating and generating a new representative still for the trimmed segment." Everything else in the independent claims is a well-trodden combination of (i) scene segmentation with representative frames (a crowded, IDS-heavy art area), (ii) client/server authoring and delivery, and (iii) the decades-old EDL conformance model. If a secondary reference expressly links derived index imagery to the edited version of a clip, or if the priority-dependence defect in § 7.3 holds, the independent claims fall cleanly. If not, expect a genuine but narrow fight over L3.

Confidence: High for the art identification numbers and dates as printed on the '894 front page; high that the Abstract-vs-claims mismatch and the post-priority EP citations are real and material; low/unverified for the specific titles of the lower-confidence rows in § 2, for the full citation list (truncated), and for the Claim 26 terminal limitations. Recommended next steps against primary sources: (1) pull the complete "References Cited" and "Cited By" tables from the Google Patents page you have open; (2) obtain the '894 file wrapper for the actual rejections and any priority challenge; (3) obtain the full granted text of Claim 26; (4) confirm the identity/title of "Ohtsena/Ottesen," "Trevitti," "Yaqoshif" and "Asile" entries, which my OCR source garbled.

Primary sources cited: https://patents.google.com/patent/US8867894/en (page text provided); https://patentimages.storage.googleapis.com/d1/d7/bb/62d859dcaeeb4c/US8867894.pdf (References Cited, OCR); https://patents.google.com/patent/US8788938#3 and https://patentimages.storage.googleapis.com/80/98/92/98cdf7debf5ebd/US10237067.pdf (verification of US 5,835,667 A, Wachter et al., 11/1998); https://patents.google.com/patent/US9390755 and https://patents.google.com/patent/US10867635B2/en (family records: US 6,882,793 B1; US 6,721,361 B1; US 13/919,825).