US 8977860

I'll search for litigation and verification details on this patent number, then summarize.

Let me pull the claim set and check for any docket activity.

Let me try to retrieve the actual claim set, since the provided text is truncated before the claims.

Summary of US 8,977,860 B2

Important sourcing caveat up front: The authoritative full text supplied for this analysis (the Google Patents record, fetched 2026‑09‑28) cuts off before the claims section — the description ends mid‑sentence at "…if a log is entangled with logs on multiple physical devices, or with logs." I also could not retrieve a verbatim claim set from USPTO PatentCenter, Espacenet, or other sources in my searches. So the bibliographic data below is authoritative, but the claim summaries are inferred from the abstract, Summary of the Invention, and Detailed Description rather than quoted claim language. Treat them as a reconstruction, not a transcription.

Bibliographic data (authoritative, from the patent record)

Abstract (verbatim from the record)

"A method and apparatus for maintaining a tamper proof device log are described. In one embodiment, the method comprises maintaining an embedded log in the device, the embedded log being a chain of log entries. In one embodiment, the method may also comprise publishing at least one log entry to a location external to the device."

What the specification discloses (plain language)

The patent is about making the provenance of digital media from a capture device provable rather than merely asserted:

• Content Based Identifiers (CBIs): exact‑match identifiers computed as cryptographic hashes over media bytes (optionally with a hash‑type prefix such as "sha1").
• Hash‑chained logs: each entry is a hash of new content plus the prior entry's rolling checksum, e.g. r_i = hash(r_(i−1) · t_i · m_i). Tampering breaks the chain. Logs may carry multiple parallel hash functions (SHA‑1/SHA‑256) so a later break of one doesn't invalidate the whole chain.
• Publishing / entangling: a rolling checksum from Log A is written into Log B (with a URL/location and position pointer), so the two logs corroborate each other. Cross‑boundary entanglement (different devices, companies, organizations) raises confidence.
• Camera embodiment: a digital camera keeps a master log in tamper‑resistant/inaccessible memory, mirrors it to a mirrored log on device storage (e.g., a removable flash card), and publishes entries to external systems (a logging server, a PC, an MFP, a timestamp service). New log entries are created on capture, on metadata creation (timestamp, GPS geo‑tag), and on edits (crop, rotate, resize — treated as newly "captured" media).
• Verification without keys: prior log entries are embedded as delimited metadata inside the image file (e.g., JPEG APPn markers, EXIF ImageDescription/UserComment), so a purported image can be authenticated by recomputing its CBI and matching it against log entries extracted from a known image, then iteratively chaining outward to authenticate additional images. The description states media data "may be verified from the media data file itself, without the use of cryptographic keys, passwords, etc."
• Temporal/geospatial bounding: trusted upload times (e.g., a website) and independently verifiable "freshness" anchors (a photographed newspaper or a machine‑readable barcode generated at a known time) bound when an image must have been taken.

Independent claims — best reconstruction (UNVERIFIED)

Consistent with the abstract, Summary, and the divisional nature of the case, the independent claims appear to be directed to roughly three or four of the following. I cannot confirm the exact number, order, or wording.

1. A method performed in a device: maintaining an embedded log that is a chain of log entries, and publishing at least one log entry to a location external to the device. (This tracks the abstract almost verbatim.)
2. A method for adding an entry on capture: adding a new log entry to the embedded log when media data is captured, the new entry being a hash of the media data and the most recent log entry.
3. A method of authentication: authenticating media data purported to have been captured by the device based on prior log entries and metadata associated with those entries (the iterative known‑image/hash‑chain matching described above).
4. An apparatus/device (e.g., a digital camera, or in another embodiment a cellular telephone) comprising storage holding the embedded log plus a hash engine to create entries and an interface to publish entries externally — possibly paired with a computer‑readable medium claim.

Note: for the parent patent, US 8,447,989, Espacenet lists the equivalent family title and abstract; I did not retrieve its claim set either.

Litigation / docket search — USPTO, PTAB, and CAFC

No assertion of US 8,977,860 was found in district court, PTAB/IPR, ITC, or Federal Circuit dockets in my searches. Specific findings:

• IPR2023‑00848 (Snap Inc.) — An exhibit in this unrelated PTAB proceeding contains a long prior‑art search string that happens to include "8977860" and "8447989" alongside dozens of other numbers. This is a prior‑art query string, not an assertion or challenge of the '860 patent.
• Lone Star Document Management LLC v. Ricoh USA, Inc., No. 2:26‑cv‑04469 (E.D. Pa., Judge Gail A. Wellheimer) — a patent infringement case against Ricoh USA filed 06/29/2026 with four exhibits (i.e., up to four asserted patents). I could not confirm whether US 8,977,860 is among the asserted patents. I am flagging it only as a Ricoh patent case to check. Also note a dating inconsistency: your prompt states today is April 26, 2026, while the docket record reports a June 29–30, 2026 filing. I cannot reconcile those; treat the case‑specific patent list as unverified.
• Ricoh v. Aeroflex (N.D. Cal. 5:03‑cv‑04669) and ITC Inv. No. 337‑TA‑690 appeared in results but concern unrelated Ricoh patents (e.g., 5,764,866; 6,388,771; 6,209,048) and are not relevant to the '860 patent.
• No CAFC 2026 appeal involving US 8,977,860 was found.

Uncertainty flags

• Claim text was not available to me — I did not verify any claim verbatim, and the "independent claims" overview above is a reasoned reconstruction.
• The patent family relationship is confirmed (divisional of 12/244,714 → US 8,447,989), but I did not independently verify the current maintenance‑fee / expiration status beyond Google Patents' "Active, expires 2028‑11‑11" legend, which carries a disclaimer on the record itself.
• One search result rendered the applicant as "RICOH CO₂, LTD." — an OCR artifact; the correct entity on the record is Ricoh Co., Ltd. I did not rely on that rendering.
• I did not have direct API access to USPTO PatentCenter or PACER/CAFC dockets; the litigation findings come from web search over third‑party docket aggregators and are therefore not exhaustive.

I'll search for litigation involving US patent 8977860.

Let me search more specifically for litigation and enforcement activity.

Let me try additional targeted searches on litigation databases.

Findings: Litigation involving U.S. Patent No. 8,977,860

Bottom line: I located no district court litigation, ITC investigation, PTAB proceeding, or CAFC appeal involving U.S. Patent No. 8,977,860 ("Method and apparatus for tamper proof camera logs," Ricoh Co., Ltd.; inventors John Barrus, Michael Gormish, Sergey Chemishkian).

What I searched

• General web searches for the patent number in litigation contexts (8977860 / 8,977,860 combined with "litigation," "lawsuit," "infringement," "complaint," "docket").
• Unified Patents litigation/PTAB caselist references and RPX Insight litigation documents.
• Docket Navigator–derived material (exhibits listing patent litigation) and general patent-docket sources.

What I found (and why it is not litigation of this patent)

1. A PTAB exhibit in IPR2023-00848 (Snap Inc.) — a Docket Alarm–hosted PDF (Exhibit 1017, file history of abandoned App. No. 12/953,350) contains a long prior-art keyword string that includes "8977860" alongside hundreds of other patent numbers (e.g., "8447989", "8737815", "9764044"). This is a prior-art search string, not an accusation, case caption, or party in a lawsuit. It does not indicate that US 8,977,860 was ever asserted.
   • Source: https://www.docketalarm.com/cases/PTAB/IPR2023-00848/Snap_Inc/docs/05-26-2023-Petitioner/Exhibit-1017-File_History_of_abandoned_US_Application_No_US_12953,350_.pdf
2. Patent-family / bibliographic records confirming the patent's ownership and lineage (Ricoh; divisional of U.S. Pat. No. 8,447,989). These are prosecution/assignee records, not litigation:
   • Google Patents: https://patents.google.com/patent/US8977860/en
   • Espacenet (parent US 8,447,989): https://worldwide.espacenet.com/publicationDetails/biblio?CC=US&NR=[8447989B2](/patent/8447989B2)
3. Unrelated litigation hits that surfaced only because of the search terms (e.g., Ricoh Co., Ltd. v. Quanta Computer, Inc.; Telecomm Innovations, LLC v. Ricoh Co.; MASA/Ricoh toner and Whetstone matters). None of these concern the '860 patent.

Caveats (stated explicitly, per your rules)

• My source set here is primarily public web search results; I was not able to run a direct, exhaustive query against a complete, current litigation database (e.g., full Docket Navigator or the complete PACER docket set for this patent). Litigation can exist that is not surfaced by general web search.
• The '860 patent's parent, U.S. Pat. No. 8,447,989, is the more commonly cited member of this Ricoh family and would be the more likely candidate if Ricoh (or a successor/assignee) ever enforced this camera-log technology — so if you need certainty, the '989 patent should be checked in the same databases.
• I found no evidence of any assignment of the '860 patent away from Ricoh, and no evidence of NPE ownership, which is consistent with low enforcement activity.

Recommended next steps for confirmation

1. Run the exact patent number through RPX Insight / Unified Patents Portal / Docket Navigator filtered to "patent number = 8977860."
2. Query PACER (all districts) and the ITC EDIS for the number.
3. Check the CAFC docket (via the Federal Circuit's public docket search) for appeals referencing the number.
4. Given the family relationship, also query 8,447,989 and the related Ricoh camera/authentication patents.

If you would like, I can draft the queries for those specific databases, or, given the rules you set, I will state plainly: based on the searches performed, there is no known litigation involving U.S. Patent No. 8,977,860.

Proceedings overview

Total AIA trial proceedings on file for U.S. Patent No. 8,977,860: 0. The USPTO Open Data Portal (ODP) structured block returned no IPR, PGR, or CBM proceedings for this patent, and my web searches surfaced no PTAB petition, institution decision, Final Written Decision, or Federal Circuit appeal naming the '860 patent. The breakdown by status is therefore 0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution denied.

Bottom-line defensive posture: The patent has never been tested at the PTAB, which cuts both ways. There is no canceled claim to hand you a free win, and no FWD estoppel constraining anyone — but there is also no Board precedent construing the '860 claims, no petitioner-funded invalidity record, and no evidence that the patent has ever been valuable enough to attack. Every claim of the '860 patent is UNTESTED, and the whole claim set remains live.

Important clarification on a false positive. The earlier litigation section of this analysis flagged IPR2023-00848 (Snap Inc.) as containing the string "8977860." I confirmed this is not a proceeding on the '860 patent. That reference is a prior-art keyword string in Exhibit 1017 (a file history of abandoned App. No. 12/953,350) that lists hundreds of patent numbers together, including "8447989", "8737815", and "9764044" alongside "8977860" (https://www.docketalarm.com/cases/PTAB/IPR2023-00848/Snap_Inc/docs/05-26-2023-Petitioner/Exhibit-1017-File_History_of_abandoned_US_Application_No_US_12953,350_.pdf). It is a search string, not a challenged patent. It has no estoppel effect, no claim-level outcome, and no relevance to the '860 patent's validity. Do not cite it as PTAB activity on this patent.

No proceedings to itemize

Because the structured PTAB data (the canonical source per the task instructions) lists no proceedings, there is nothing to render in the per-proceeding template. I am not populating the template with invented or inferred cases. For completeness, here is what I affirmatively checked:

• Exact-number searches for "8977860" / "8,977,860" in IPR/PGR/CBM contexts — no docket hits.
• Parent patent check: U.S. Pat. No. 8,447,989 ("Method and apparatus for tamper proof camera logs," granted 2013-05-21, the parent of the '860 divisional per Google Patents and Espacenet — https://patents.google.com/patent/[US8977860](/patent/US8977860)/en and https://worldwide.espacenet.com/publicationDetails/biblio?CC=US&NR=[8447989B2](/patent/8447989B2)). No PTAB proceeding surfaced on the '989 patent either, though per the caveats below this should be independently confirmed in a docketing database.
• Family/prosecution records only — the hits were bibliographic and prosecution documents, not adversarial proceedings.

Caveat stated plainly, per the operating rules: My verification here rests on the ODP structured feed plus public web search. I could not run a direct, exhaustive query against PTAB E2E, the PTAB API, or Docket Navigator. A recently filed, sealed, or unindexed proceeding could exist that neither the ODP ingest nor web search surfaced. Treat "zero proceedings" as reported, not proven, until you re-run the number in PTAB E2E and Docket Navigator.

Strategic summary

Claim status: all claims of 8,977,860 remain fully intact and untested. No claim — independent or dependent — has been canceled, disclaimed via a statutory disclaimer in an IPR, or narrowed by a certificate of correction arising from a trial. There are no surviving claims to list because there are no lost claims; the assertion set in any demand letter is whatever the patent owner chooses to assert, and the PTAB has said nothing about any of it. Note the patent's adjusted expiration of 2028-11-11 (Google Patents legal-status field), so the enforcement window is not close to closing and a challenge remains economically rational for years.

Estoppel landscape: no § 315(e) estoppel exists, because estoppel attaches only upon a Final Written Decision. Under § 315(e)(2), a petitioner is barred in district court only as to grounds it raised or reasonably could have raised after a final written decision issues. With zero FWDs, no petitioner anywhere is estopped on this patent. For a defendant now facing assertion, that means the entire prior-art universe under §§ 102 and 103 is available — in an IPR, in an ITC invalidity defense, and at trial — with no procedural haircut. You can also raise § 112 (written description, enablement, indefiniteness) and § 101 in district court, which IPR cannot reach (35 U.S.C. § 311(b) limits IPR to patents and printed publications under §§ 102/103). If you file an IPR, be aware that the estoppel will then run against you after FWD, so serially decide which grounds go to the Board and which stay in court.

Pattern signals: none. There is no serial petitioner, no multi-petition campaign, no patent-owner appeal activity, and no defensive aggregator visible. Critically, there is no Unified Patents or RPX challenge on record — Unified in particular tends to target camera/capture-integrity and imaging patents when they circulate in NPE hands, so its absence is a weak but real signal that this patent has not been monetized at scale. Ownership appears to remain with Ricoh Co., Ltd. (original and current assignee per Google Patents; reassignment recorded 2013-12-18 assigning Barrus, Gormish, and Chemishkian to Ricoh), with no evidence of NPE or aggregator assignment — consistent with the low enforcement activity noted in the litigation section.

Also worth flagging for a defendant: because the '860 patent is a divisional of U.S. Pat. No. 8,447,989, the two patents share a specification and a 2008-10-02 priority date. A validity challenge should be scoped across the whole family, not just the one patent you were handed — prior art that invalidates the '860 claims may equally reach the '989 claims, and vice versa. Conversely, if you attack only the '860 patent, the patent owner may simply assert the '989 patent and force you to start over.

Recommended next steps

1. Confirm the null result before relying on it. Run 8977860 through PTAB E2E (https://ptab.uspto.gov) and Docket Navigator with the filter "patent number." Re-run the identical query for 8447989 and the sibling continuation. Zero PTAB activity is a strong defensive signal only if the search is exhaustive; a single missed recent IPR changes the analysis materially.

2. Because no claims are invalidated, there is no FWD to link or quote. I cannot point you to a disposition — none exists. Any statement that claims of the '860 patent "have been canceled" would be false, and any demand letter implying PTAB history for this patent should be read as a bluff.

3. Preserve your IPR filing window. With no FWD and no estoppel, the only hard deadlines are personal to you: § 315(b)'s one-year bar from service of an infringement complaint, and § 315(a)(1)'s bar if you filed a declaratory-judgment action of invalidity before the petition. Diary the § 315(b) date the moment you are served. If your opponent threads the needle by asserting the '989 parent instead, calendar that separate § 315(b) date too.

4. Verify the statutory windows for petition type. The '860 patent issued 2015-03-10; the nine-month PGR window closed 2015-12-10, so PGR is unavailable. CBM expired for new petitions on 2020-09-16 and, in any event, a camera-log/integrity patent would face a difficult "covered business method" eligibility argument. IPR is your only realistic PTAB vehicle.

5. Build the invalidity record from scratch. Since no petitioner has worked up art, budget for a full prior-art search against the 2008-10-02 priority date, focusing on hash-chain / tamper-evident logging literature and camera-authentication prior art. The specification's own admissions are unusually useful here — it expressly describes rolling checksums, write-once memory logs, and log "entangling" as known techniques, which are § 103 lead references against the claims (see the Detailed Description discussion of r_i = hash(r_{i-1} · M_i) and the publishing/entangling sections).

6. Check whether a parallel district court invalidity holding exists — a district court judgment of invalidity would not appear in the PTAB feed at all. My litigation search found no such case, but the earlier litigation section's caveat applies: no exhaustive PACER/Docket Navigator sweep was run.

If you want, I can draft the exact PTAB E2E and Docket Navigator query strings, or map the '860 claim set to candidate § 102/§ 103 grounds drawn from the specification's admitted prior art.

I'll research the assignment record for US 8,977,860. Let me run targeted searches.

Let me try more targeted queries on the assignment record and legal events.

Let me check patent registry mirrors that reproduce assignment/correspondent data.

Assignment & Ownership Reconstruction — U.S. Patent No. 8,977,860

Sourcing note (read first). I was not able to execute a live query against USPTO Assignment Center (https://assignmentcenter.uspto.gov/) or its legacy mirror (https://assignment.uspto.gov/patent/index.html) — both are interactive search applications that my web-search tooling cannot drive directly, and no third-party mirror I could reach reproduces the reel/frame or correspondent fields for this specific patent. The assignment facts below therefore come from the legal-events block of the authoritative patent record (the Google Patents record supplied for this analysis, fetched 2026-09-28), which records the existence, date, conveyance type, assignor, and assignee of the one assignment it surfaces. Every field I could not verify — reel/frame, correspondent, and exact execution date — is marked "not retrieved" rather than filled in. Per the operating rules, I have not inferred or fabricated any assignment record.

---

Inventors

Confidence caveat. The residences are from the patent record. The employer attribution to Ricoh Innovations, Inc. is a reasoned inference from (a) all three being named on a patent assigned to Ricoh Co., Ltd., (b) all three residing in the Bay Area, and (c) the specification's own framing of a networked camera/MFP/scanner ecosystem consistent with Ricoh's imaging business. I did not independently confirm employment records for this session.

Unusual-pattern check — inventors departing within 12 months of filing: No such pattern is evident from the record available. The three inventors were named on the parent application (Ser. No. 12/244,714) filed 2008-10-02, and the same three are listed as assignors on the assignment recorded 2013-12-18 — meaning all three were still the assignors of record five years after the 2008 parent filing and after the 2013 divisional. That continuity is the opposite of the pre-fire-sale departure pattern. I found no evidence of any of the three assigning away personal rights independently, and no evidence of their departure preceding any transfer. (Note: a 5-year record gap before recording can itself suggest the 2013 recording was a confirmatory/clean-up filing tied to the divisional, not a market event — see the context line below.)

---

Original assignee

Ricoh Co., Ltd. (Tokyo, Japan) — named as both original assignee and current assignee on the face of the record.

• Primary line of business: imaging and electronics — multifunction printers (MFPs), copiers, printers, scanners, digital cameras (Ricoh/Pentax-branded), and document-management software. The specification's examples (MFP, network scanner, digital camera) map directly onto Ricoh's product lines.
• Product embodying the claims: Unclear / not established. Ricoh ships devices squarely within the claims' field (digital cameras, MFPs, network scanners with embedded imaging pipelines), but I found no evidence that any Ricoh shipping product implements the specific claims — no product literature, standard, or technical documentation tying the hash-chained camera log to a commercial device. The specification reads as a research/architecture disclosure from Ricoh's Silicon Valley lab rather than a shipped-feature description.
• Current status: Operating. Ricoh Co., Ltd. is an active, publicly traded Tokyo-listed conglomerate. No bankruptcy, dissolution, or Chapter 7/11 event was found for Ricoh or any affiliate in connection with this patent. There is no record of the patent being swept into an IP divestiture.

---

Assignment timeline

Exactly one assignment is surfaced on the record for application 13/898,325 / patent 8,977,860. No post-issuance reassignment, security interest, license, release, merger, or change-of-name record appears in the legal-events block.

• Execution date not retrieved / recorded 2013-12-18 — Reel/Frame not retrieved
  • Conveyance: Assignment of assignors' interest ("ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS)")
  • Assignor: John Barrus; Michael Gormish; Sergey Chemishkian (individual inventors)
  • Assignee: Ricoh Co., Ltd. (Tokyo, JP)
  • Correspondent: Not retrieved. I could not obtain the attorney/agent of record who filed this recording. This is the single most important unfilled field for NPE-pattern purposes, and I am flagging its absence explicitly rather than guessing.
  • Context: Initial inventor-to-corporate assignment (original acquisition by the operating company), recorded late. The recording came on 2013-12-18, after the divisional was filed (2013-05-20), which is consistent with a confirmatory/clean-up recording flowing from the divisional rather than arm's-length consideration. There is no transfer to any third party.

What this means practically: because the chain shows no post-issuance assignment whatsoever, the strong presumption is that Ricoh Co., Ltd. still owns the patent outright. This is the ordinary, benign outcome — it is not a "no records" situation, but it is effectively an original-assignment-only chain.

Family note. The '860 is a divisional of Ser. No. 12/244,714 → U.S. Pat. No. 8,447,989 (issued 2013-05-21), and the same three inventors are the assignors in this record. Any assignment recorded against the parent or the sibling continuation should be pulled separately; because they share the specification, assignee, and 2008-10-02 priority date, the ownership chain is substantively identical across the family, but the individual reel/frame records may differ and each application can carry its own recording. I did not retrieve the '989 record.

---

Timeline diagram

timeline
    title Ownership of US 8977860
    2008 : Parent application filed by inventors
    2013 : Divisional application filed 20 May
         : Inventors assign to Ricoh recorded 18 Dec
    2015 : Patent issued 10 Mar

(Note: the Mermaid renderer does not cleanly express a "no further assignments" state — the chain simply terminates at Ricoh in 2013 and remains there through issuance and to the present.)

---

NPE / troll-pattern signals

Cross-check against asserter directories: I found no RPX Insurance or Unified Patents listing, and no high-frequency-plaintiff directory entry, identifying US 8,977,860 or Ricoh Co., Ltd. as an asserter for this patent. (The earlier sections of this analysis note the single appearance of the string "8977860" in the IPR2023-00848 (Snap Inc.) Exhibit 1017 prior-art query — that is a search string, not ownership or assertion evidence, and I do not treat it as a signal.)

---

Verdict

Insufficient data — on the strict rubric, this is the correct label because the chain consists of only the original inventor→Ricoh assignment recorded 2013-12-18, with no post-issuance record of any kind. To be clear about what that label does and does not mean: it is not a red flag here. Every NPE signal is not present (with signal #3 merely unclear for want of the correspondent field), the assignee is an operating company, ownership appears unbroken and unencumbered by any assignment, and no litigation or PTAB activity naming the patent was found. The practical conclusion is therefore benign: this is a clean operating-company-owned patent that has never been transferred to a licensing entity — the opposite of a troll-chain profile.

Verification link: Re-run the number yourself at the USPTO Assignment Center search page — https://assignmentcenter.uspto.gov/ (legacy: https://assignment.uspto.gov/patent/index.html) — searching by patent number 8977860 and by application number 13/898,325, and pull the reel/frame and correspondent that I could not retrieve. Also run 8447989 (the parent) to capture any family-level recordings.

---

Open items I could not close (stated plainly)

1. Reel/frame for the 2013-12-18 assignment — not retrieved.
2. Correspondent of record (attorney/agent and firm) — not retrieved; this is the field most relevant to signal #3 and it is unfilled.
3. Exact execution date of the assignment — not retrieved (record shows only the 2013-12-18 recording date).
4. Any assignment recorded against the parent '989 or the sibling continuation — not retrieved.
5. Whether any Ricoh product practices the claims — not established from public sources.

Internal strategy analysis, not a legal opinion or a title/chain-of-title certification. Ownership conclusions should be confirmed against the official USPTO Assignment Center record before being relied upon. Note also the unresolved date discrepancy flagged in the earlier sections of this analysis (the prompt's stated current date versus a 2026 docket date cited earlier in the chain); it does not affect the assignment findings above.

I'll research the prior art citations for US 8,977,860. Let me run several targeted searches.

I found the "References Cited" list. Let me now verify the claim set and gather details on the key references.

Prior-Art Analysis — U.S. Patent No. 8,977,860

Sourcing note (read first)

I ran web searches keyed to the exact number, 8977860, and did not conflate it with similar numbers. I was not able to execute a live, direct query against USPTO PatentCenter/PAIR full‑text search; the reference list below comes from the front‑page "References Cited" of the specific patent record (mirrored on Justia) and the Google Patents record, both of which reproduce the USPTO front page. Where a date or characterization is not something I independently confirmed against the patent document itself, I say so explicitly.

One correction/upgrade to the earlier sections: the previous "Patent summary" flagged that the claim set was unavailable and offered a reconstruction. I have now recovered claim 1 verbatim as published in the pre‑grant publication US 2013/0262871 A1 (the pre‑grant publication of this same application, 13/898,325 — it appears under "Other versions" of the '860 on Google Patents):

"1. A method, comprising: obtaining a media data file known to have been captured by a media capture device; obtaining purported media data files alleged to be captured by the media capture device; extracting log entries from the known media data file; and verifying authenticity of the purported media data files based on the extracted log entries…"
— https://patents.justia.com/patent/20130262871#4

This maps to reconstruction item #3 in the earlier summary. Caveat: these are the published claims; the granted '860 claims could differ, and I did not verify the granted claim set or the dependent claims.

A second flag: your current prompt says today is April 26, 2026, while the earlier litigation section reports a Ricoh docket entry dated June 29, 2026. I cannot reconcile those and treat the date discrepancy as unresolved (it does not affect the prior‑art analysis).

---

A. What "references cited" means for §102 purposes

The list below is what appears on the face of US 8,977,860. Being cited is not the same as anticipating. Three cautions:

1. Effective filing date. The '860 is a divisional of 12/244,714 (filed Oct. 2, 2008), so pre‑AIA §102 applies and the critical date for §102(b) art is Oct. 2, 2007. Two listed references issue after that date (US 7,849,053; US 8,006,094) and therefore cannot be §102(b) art on the 2008 priority; at most they may be §102(a)/(e) art if their pre‑grant publications predate Oct. 2, 2008, or they were cited as background. US 2008/0243688 A1 published Oct. 2, 2008 — the same day as the priority filing — so it is borderline.
2. Anticipation requires every element in one reference. Anticipation is a per‑claim, all‑elements test. I cannot responsibly map each reference to specific claims because I only have verified text for claim 1, not the full granted claim set.
3. Many of these are classic background art (digital‑signature camera authentication), which the specification itself implicitly distinguishes by emphasizing verification "without the use of cryptographic keys."

---

B. U.S. patent documents cited on the face of US 8,977,860

I have deliberately not invented titles or subject matter for entries 3–7, 9–16, 19–24. If you need the full citation/abstract for each, the next step is to pull each record individually (Google Patents / USPTO PatentCenter / Espacenet).

---

C. Non‑patent literature cited

---

D. Forward citations (context, not prior art)

US 8,977,860 is itself cited by later Ricoh and third‑party filings, e.g. US 11,941,090 ("Encoding alteration metadata within media data") lists 8977860 | March 10, 2015 | Barrus et al. among its references. This is useful for showing the patent's citation footprint but is not prior art against the '860.

Also note: the same family member appears as US 2010/0088522 A1 (the parent publication, Barrus et al., Apr. 8, 2010) and the parent patent US 8,447,989. These are the same invention, not prior art against the '860.

---

E. Bottom line — most relevant prior art, and honest limits

The three references of substantive relevance that I can affirmatively verify are:

1. US 5,978,475 (Schneier et al., Nov. 2, 1999) — hash‑chained audit log with previous‑entry hashing and cross‑process "entangling." Closest art to the log‑chaining and publishing concepts.
2. US 5,499,294 (Friedman, Mar. 12, 1996) — digital camera image authentication by hashing the image and signing/encrypting the hash, then verifying by recomputation. Closest art to the camera‑authentication concept.
3. Blythe et al., "Secure Digital Camera," DFRWS 2004 — camera‑side secure/forensic image capture.

My §102 assessment: Based on the text of the only claim I can verify (published claim 1, which requires extracting log entries from the known media data file and using those extracted entries to verify purported media data files), I do not identify any cited reference that appears to disclose that combination in a single reference. Friedman and Schneier each capture parts of the broader concept but appear to lack the specific element of log entries embedded in a known media file being extracted and used to authenticate other purported files. They are therefore better characterized as §103 (obviousness) candidates or background art than as clear §102 anticipations — and Friedman is a notable contrast reference, since the '860 specification stresses verification "without the use of cryptographic keys," which is precisely what Friedman requires.

What I could not do, stated plainly:

• I did not obtain the full granted claim set of US 8,977,860 (only published claim 1), so I cannot assign references to specific dependent claims.
• I did not independently verify the title/subject matter of 16 of the 24 patent‑document references, nor the filing dates of most of them (I only have the front‑page dates).
• I did not run exhaustive full‑text searches of USPTO/EPO/WIPO for uncited prior art; the list above is confined to references of record on this patent, as requested.

If you want, I can resolve the 16 unverified entries by pulling each patent individually, or re‑run the analysis as a §103 obviousness matrix once the granted claims are in hand.

I'll ground the key references before building the §103 matrix.

Obviousness Analysis — U.S. Patent No. 8,977,860 under 35 U.S.C. § 103

Analyst's note on inputs. Per the task instruction, this analysis is built on the reference set developed in the Prior Art section of this page (the references of record on the '860 patent, plus the parent/family context). I have supplemented nothing new to the reference list; where I did re-verify a reference, the source is cited. The claim-text gap flagged in the earlier sections persists and governs everything below: the only verbatim claim language available is published claim 1 of pre-grant publication US 2013/0262871 A1 (the "Other version" of application 13/898,325 — https://patents.justia.com/patent/20130262871#4). The granted '860 claim set was never recovered. Accordingly, this is an element-based obviousness assessment against a reconstructed claim scope, not a chart against verified granted claims.

---

A. Legal framework and the effective date that controls

• Pre-AIA § 103 applies. The '860 is a divisional of Ser. No. 12/244,714, filed October 2, 2008 (now US 8,447,989), which is the priority date on the face of the record. Because all claims have an effective filing date before March 16, 2013, § 103(a) governs, with the Graham v. John Deere factors: scope/content of the prior art, differences, PHOSITA level, and secondary considerations. (Consistent with the earlier sections, I am not re-litigating the date discrepancy in the prompt.)
• Critical date for § 102(b)/§ 103 art = October 2, 2007. This matters: Schneier '475 (1999), Friedman '294 (1996), Haber & Stornetta (1991), and Blythe & Fridrich (2004) are all comfortably before it.
• KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007) controls the combination question. The specification's own framing — that it merely improves known rolling-checksum logs, write-once memory, and log "entangling" — is the classic KSR posture: "a patent composed of several elements is not proved obvious merely by demonstrating that each of its elements was, independently, known in the prior art," but where the improvement is a predictable combination of known techniques applied for their known purposes, it is obvious.
• Two of the on-record references (US 7,849,053; US 8,006,094) issue after the § 102(b) critical date and are usable at most under § 102(a)/(e); I do not rely on them.

---

B. Element inventory (the scope that must be overcome)

Reconstructed from the abstract, Summary, Detailed Description, and published claim 1:

---

C. Level of ordinary skill in the art (PHOSITA)

A person having ordinary skill as of October 2008 in this field would hold a B.S. in electrical engineering or computer science (or equivalent), with 2–4 years of experience in digital imaging systems and applied cryptography (or a master's degree plus 1–2 years). That person would be familiar with: cryptographic hash functions and their collision properties; digital signature schemes; the EXIF 2.2 / JPEG APP-marker file structures; audit-log integrity and time-stamping designs; and the forensic-evidence problem of proving a photograph's origin. The '860 specification itself confirms this level — it treats rolling checksums, write-once memory, entangling, HMAC, and EXIF as known building blocks rather than inventions, e.g. "This method of creating a log meets most of the goals for the log, but there are variations which provide additional benefits."

---

D. Ground-by-ground § 103 analysis

Ground 1 — Claims to the camera-resident chained log: Schneier '475 in view of Friedman '294

Schneier (US 5,978,475, "Event auditing system," Nov. 2, 1999 — https://patentimages.storage.googleapis.com/f0/d2/50/2559ccc45e36cb/US5978475.pdf ; claim text at https://insight.rpxcorp.com/patent/[US5978475A](/patent/US5978475A)) teaches nearly all of E1–E4:

• Element-by-element: Claim 1 recites "(b) concatenating said quantity with at least a portion of a verification chain entry for a preceding entry" and "(c) … performing a verifiable cryptographic operation on the result of step (b) to generate a current verification chain entry" — i.e., rⱼ = hash(rⱼ₋₁, dataⱼ). That is the '860's r_i = hash(r_{i−1} · M_i) almost verbatim, and the Board-style mapping in the PTAB record for a different patent confirms the equation form: "Y_j = hash(Y_j-1, E_Kj(D_j), W_j)" (see the § 103 petition excerpt at https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1539042](/patent/1539042)/download-documents?artifactId=wjjGqquFsdiNKGBDeKgrCE5p0DqvaYJefPHHUHP0Nahi9mLVv50Lbzo#11#10).
• Schneier expressly frames the application environment: "3) a secure digital camera that needs to guarantee the authenticity of pictures it has taken" (col. 1, Background).
• Schneier discloses E3-class externalization: "the untrusted machine's log file can also incorporate log files of other processes" (Abstract).
• Schneier discloses E4-class non-rewritable storage: "Non-rewritable storage device 170 includes any medium characterized in that once a record is written thereto, the record cannot be altered or deleted without detection" (https://uspto.report/patent/grant/[5978475](/patent/5978475)).
• Schneier discloses transitive verification (E8-class): verifying the current hash-chain entry "validates all prior log entries by transitivity."

Friedman (US 5,499,294, Mar. 12, 1996 — https://be.espacenet.com/publicationDetails/biblio?locale=en_BE&CC=US&II=14&date=19960312&NR=[5499294A](/patent/5499294A)) supplies the missing "capture device" locus in concrete form: a digital camera "processor [that] comprises means for calculating a hash of the image file," storing the hash "along with the image file," and recomputing on authentication.

Why a POSITA would combine — motivation (KSR factors):

1. Schneier's own words supply the suggestion. The reference names the secure digital camera as a target application. In re ICON Health & Fitness, 496 F.3d 1374 (Fed. Cir. 2007) — a reference's explicit identification of an application is a suggestion to apply it there.
2. Same field of endeavor. Both address tamper-evidence for captured records; In re Bigio, 381 F.3d 1320 (Fed. Cir. 2004).
3. Friedman supplies the implementation that Schneier leaves generic (a hash engine inside a camera that already hashes image files). Nothing more than the routine substitution of a known element for a known function.
4. Predictable result, no new operation. Concatenating the prior image's hash with the new image's hash in-camera is the same arithmetic Schneier already teaches, merely run inside the camera.

---

Ground 2 — Claims to publishing/entangling (E3): Schneier '475 in view of Haber & Stornetta

Haber & Stornetta, "How to Time-Stamp a Digital Document," J. Cryptology 3(2):99–111 (1991) (DOI 10.1007/bf00196791; http://zbmath.org/pdf/0800.68408.pdf), teaches the linked time-stamp chain certified by an external Time-Stamping Service (TSS), where the nth certificate is

Cₙ = (n, tₙ, idₙ, yₙ; Lₙ) with Lₙ = (tₙ₋₁, idₙ₋₁, yₙ₋₁, H(Lₙ₋₁))

and the TSS returns the next client's identifier so the chain can be walked forward and backward by a challenger. Critically, Haber also teaches that a client hashes the document and sends only the hash to the external service — the same privacy-preserving publication the '860 uses.

Motivation to combine — and it is unusually strong because the linkage is express:

• Schneier's own Background cites Haber's technique: Schneier's patent lists Haber as the known approach for "writing a hash of an immediately preceding file into each current file" (see the citation discussion in the '602 petition at https://ptacts.uspto.gov/ptacts/public-informations/petitions/1539042/download-documents?artifactId=wjjGqquFsdiNKGBDeKgrCE5p0DqvaYJefPHHUHP0Nahi9mLVv50Lbzo#11#10). A reference that cites the other as the state of the art is the paradigm KSR v. Teleflex suggestion.
• Haber solves a problem Schneier identifies. Schneier's own write-once-memory discussion states the limitation: "While write once memory is simple, it is hard to verify remotely that it hasn't been tampered with." Haber's external TSS is a known solution to exactly that problem (external anchoring by an entity outside the device's control) — a known technique to improve a similar device in the same way, and the combination yields no more than the predictable benefit of third-party presence.
• The '860 spec itself describes publishing/entangling as known and even states the rationale: "if a log is entangled with logs on multiple physical devices, or with logs which are under the control of different companies, then confidence in verification of the logs will be increased." That sentence is an admission of the motivation.

---

Ground 3 — The core verification method (E7/E8/E9): Blvthe & Fridrich in view of EXIF 2.2, Friedman '294, Schneier '475, and Haber/Stornetta

This is the ground that reaches published claim 1 ("obtaining a media data file known to have been captured by a media capture device; obtaining purported media data files alleged to be captured by the media capture device; extracting log entries from the known media data file; and verifying authenticity of the purported media data files based on the extracted log entries").

Motivation (articulated reasoning, KSR factors):

• Blythe & Fridrich state the identical problem the '860 poses: "Digital images are not easily acceptable in a court because it is difficult to establish their integrity, origin, and authorship"; "The integrity of digital images as evidence rests on the accurate answering of a simple question: Who did what when?" Same problem → motivation to apply the log-chaining solution to it.
• The '860's spec expressly relies on this very reason to embed: "the camera log information is written in a location of an image file that will not be changed by image or metadata applications … delimited manner that enables easy extraction." Making the log metadata robust against downstream image processing is a predictable requirement once you have decided (à la Blythe) to embed.
• Using a trusted/known reference to bootstrap trust in unknowns is a known technique — Haber's TSS certificate, and the well-understood "trust anchor" model. Applying it to a known image file as the anchor rather than a TSS is a change in form, not in substance.
• Reasonable expectation of success. Every step is a deterministic hash-recompute-and-compare over bytes; the outcome is binary and predictable (Friedman: "even one bit change in the image hash will cause the image hash to be totally different from the secure hash").

Honest weakness. This is the thinnest link in the whole invalidity case, and it is the same gap the earlier § 102 section flagged: I do not have a reference that expressly teaches extracting embedded log entries from a known image and using those extracted entries to authenticate a set of purported images, chained iteratively. That specific combination is assembled from (i) embedding for forensic integrity (Blythe/EXIF), (ii) hash comparison against a stored hash (Friedman), and (iii) chain traversal (Haber/Schneier). It is a strong § 103 case, not a § 102 case — and it will live or die on how the granted claim recites the "extracting … from the known media data file" limitation and whether the defendant can supply a secondary reference expressly teaching the known-file-as-trust-anchor step.

---

Ground 4 — Metadata chaining and temporal/geospatial context (E5, E11): Friedman '294 (+ EXIF 2.2)

Friedman is a direct hit on the "metadata is hashed alongside the image and stored in the file" concept. As recorded in a PTAB record analyzing Friedman: "Friedman's digital camera 10 combines the measurement data … together with a time of image capture, into a border of an image frame for storage in an image file … the image file, including the augmented measurement, i.e., the image frame border with the measurement data and time of capture, is hashed by a hashing microprocessor 12a, and subsequently encrypted" (https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1493654](/patent/1493654)/download-documents?artifactId=JkeyvZ95Q0uLsBWcAaMJ_EE7e0qxqTFPSOytIUEm68_Gnt6PSbx0QTM#8#7). It also records geospatial-style measurement data — "color temperature, latitude and longitude, light level, and/or distance to objects" — and a tamper-responsive clock (zeroing time/data fields on tampering).

• Motivation: the '860's dependent concepts (timestamp + geospatial marker chained into the log) are the same objects Friedman already records and hashes; substituting GPS for Friedman's other measurements is the substitution of one known sensor channel for another.
• Freshness / E11: Haber & Stornetta's whole design rationale is making "infeasible for a user either to back-date or to forward-date his document, even with the collusion of a time-stamping service" — the same objective the '860 achieves with the photographed newspaper/barcode. Combined with the '860's admitted known practice of third-party timestamp services, E11 is an obvious application of the anchor concept.

---

Ground 5 — Multiple/parallel hash functions (E10): Schneier '475 in view of the admitted art in the '860 specification and the contemporaneous collision literature

Schneier teaches layered cryptographic redundancy on the same chain: an unkeyed hash chain entry plus a keyed MAC over it (Y_j = hash(...), Z_j = MAC_Aj(Y_j)), i.e., two independent cryptographically-strengthened values over the same data for the same entry.

• Motivation to go from "hash + MAC" to "SHA-1 + SHA-256" is supplied by the 2004–2005 MD5/SHA-1 collision results (public before the Oct. 2, 2008 filing) and by the well-known principle that hash functions age. Haber & Stornetta's own corpus discusses re-timestamping/re-signing with new functions before the old ones become exploitable. And the '860 specification admits the technique: "if one hash function is broken, the other hash function may still be valid, and the combination of both is likely to be even harder to break." Under In re Corkill, 771 F.2d 1496 (Fed. Cir. 1985), where the reference teaches that certain variables "can be" used, the selection of specific values is obvious. This is a textbook KSR "predictable variation."

---

Ground 6 — Secondary/cumulative references (flagged as unverified)

The '860's of-record list contains a substantial cluster of 1996–2001 camera/data-authentication patents — US 5,751,809 (Davis), US 5,946,396 (Davis), US 5,966,446 (Davis), US 5,898,779, US 5,898,799 (Murayama), US 6,188,766 (Kocher), US 6,269,446 (Schumacher), US 6,968,058 (Kondoh), US 7,162,637 (Wakao), US 7,194,630 (Iwamura) — plus published applications US 2002/0114452, US 2004/0123242, US 2004/0220975, US 2005/0169499, US 2006/0010095. I expressly did not verify the subject matter of these references in this session (the Prior Art section flagged 16 unverified entries and I have not cured that gap). They are relevant as cumulative evidence that device-side hash-and-store authentication was a crowded, well-developed field by 2008 — which supports the KSR "finite number of identified, predictable solutions" rationale — but they should not be charted in a petition until each is pulled and read.

One additional of-record NPL item — Lukas, Fridrich & Goljan, "Digital Camera Identification from Sensor Pattern Noise," IEEE TIFS 1(2), June 2006 — is background for camera attribution and reinforces the same crowded-field point.

---

E. Synthesis: the motivation-to-combine case in one place

Reasonable expectation of success: high. Every constituent step is a deterministic, binary, byte-level hash comparison, with years of deployed art behind each.

---

F. Counterarguments a patent owner will raise — and my assessment

1. "The '860 verifies without keys; Friedman and Schneier require keys." Assessment: moderate risk. Friedman's comparison step is unkeyed hashing; the RSA layer is severable. But if a granted claim recites keyless verification as a negative limitation, the patent owner will argue the art teaches away from removing the signature (which is what makes the record "non-repudiable"). This is where the § 112/claim-construction fight and the § 103 fight converge.
2. "The art hashes the image itself, not prior log entries extracted from a known image used to authenticate other images." Assessment: the strongest defense. Ground 3 is a combination attack on this element; absent a reference that expressly teaches the known-file trust-anchor workflow, expect the patent owner to argue improper hindsight (the Graham "temptation to read into the prior art" warning).
3. Teaching away / different purpose. Schneier is about untrusted host log security; Haber is about time-stamping; Friedman is about evidence integrity. A patent owner will argue distinct purposes. Rebuttal: KSR rejects the "rigid insistence on a single reference or a rigid application of the teaching-suggestion-motivation test," and all three share the common purpose of making post-hoc alteration detectable.
4. Evidentiary discipline is decisive. The contested petition on a different patent at https://ptacts.uspto.gov/ptacts/public-informations/petitions/1539042/download-documents is a valuable cautionary example: a Schneier + Haber combination was attacked on the ground that the petitioner's expert supplied disclosure Schneier did not contain, and that "obviousness requires a suggestion of all limitations in a claim" (CFMT, Inc. v. Yieldup Int'l, 349 F.3d 1338 (Fed. Cir. 2003)). Any § 103 ground here must be built with explicit pin cites and no expert-supplied gaps — this is the single biggest execution risk.
5. Secondary considerations. None is apparent from the record available: no evidence of commercial success tied to these claims, no long-felt-need narrative, no copying allegation, no praise. The patent has never been litigated or challenged at the PTAB (per the earlier PTAB section), so there is no nexus evidence to rebut.

---

G. Claim-by-claim risk assessment (reconstructed scope)

---

H. Bottom line

The '860 claims are, on the record available, vulnerable under § 103 — but the vulnerability is concentrated in the combination that reaches the "extract entries from a known file" workflow, not in the camera-log elements. The camera-resident chained log, the on-capture entry (hash(media, prior entry)), external publishing/entangling, non-rewritable master storage, metadata chaining, and parallel hash functions are each taught or suggested by the of-record art and are combinable on strong, citable motivations — including the unusually powerful facts that Schneier expressly names the secure digital camera and that Schneier's own background cites Haber's chaining technique. Those elements should be expected to fall on summary judgment-worthy grounds.

The genuinely contested element — E7, verifying purported files from log entries extracted from a known file — is a § 103 combination of Blythe/Fridrich (forensic embedding), EXIF 2.2 (the metadata container), Friedman (hash-and-compare), and Schneier/Haber (chain traversal). That is a defensible obviousness case on articulated KSR reasoning, but it is not a § 102 case and it requires disciplined pin-citing to survive the kind of attack that defeated the Schneier+Haber petition on the unrelated '602 patent.

Two things must happen before this analysis can be relied on:

1. Obtain the granted claim set of US 8,977,860 (PatentCenter / the issued patent PDF) and re-run this map against the actual claim language — particularly whether any claim recites keyless verification or the known-file extraction step in a way that forecloses the combinations above.
2. Read the 16 unverified of-record references (Section D, Ground 6) and pull uncited hash-chain camera-provenance art against the October 2, 2008 date. Per the earlier strategic section, any challenge should be scoped across the family — the divisional parent US 8,447,989 shares this specification and priority date, so art that defeats the '860 claims will reach the '989 claims too, and vice versa.

This is a technical patent analysis prepared for internal strategy purposes. It is not a legal opinion, not a validity determination, and not a substitute for a formal freedom-to-operate or invalidity opinion by counsel. All claim language other than published claim 1 of US 2013/0262871 A1 is reconstructed and unverified.