US 8775878

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

Let me run additional targeted searches for litigation and docket records.

I have the authoritative full text. Let me do one more check on claim language and any 2026 appellate activity.

Summary — US Patent No. 8,775,878 B2

A note on sourcing and verification: My searches did not surface a separate USPTO record page or any CAFC 2026 docket entry for this specific number. The authoritative source available to me is the full patent text at Google Patents (https://patents.google.com/patent/[US8775878B2](/patent/US8775878B2)/en), which I rely on below. I found no evidence of any 2026 Federal Circuit or district-court litigation involving U.S. Patent No. 8,775,878 — if such a docket exists, it was not retrievable via my searches, so treat that null result as inconclusive rather than as proof of absence. I also caution against conflating this patent with similarly-numbered assets that do appear in litigation, e.g. U.S. Pat. No. 10,877,266 / 10,877,267 (Optimum Imaging v. Canon, W.D. Tex.) or the "878 patent" in Multimedia Patent Trust (that one is U.S. Pat. No. 5,227,878). I am treating the identifier 8775878 literally.

Bibliographic data (per the authoritative patent text)

Abstract (as published)

An information processing apparatus (a "device proxy server") is connected to a printer and a client PC via a network. The server receives an event message indicating an event that occurred in the printer and transfers it to the client PC. When the transferred message relates to an error event in the printer, the server monitors whether the error has been eliminated. When the error is eliminated, the server sends an error recovery message to the client PC.

Technical problem addressed

Inexpensive printers store event-subscription (registration) information in volatile memory (RAM), so it is lost on power cycling. Such a printer therefore cannot reliably send an error-recovery notification, leaving client PCs permanently believing the printer is faulty. The invention offloads the error-recovery duty to the proxy server.

Plain-language overview of the independent claims

Caveat on claim text: The full claim set was not included in the text I retrieved. The description states the invention in four "aspects," which correspond to the four independent claims. I summarize those aspects below; I have not independently verified the exact claim numbers, wording, or claim boundaries. Treat the numbering as inferred, not confirmed.

1. Information processing apparatus (apparatus claim). A server connectable to a terminal (printer) and a client over a network, comprising:

• a reception unit that receives an event message indicating an event that occurred in the terminal;
• a transfer unit that forwards the received event message to the client;
• a monitoring unit that, when the transferred message concerns an error event, monitors whether the error has been cleared at the terminal; and
• a notification unit that, once the error is cleared, sends an error-recovery message to the client.

In short: the server sits between printer and PC; it relays error events, then polls the printer and tells the PC when the printer is healthy again.

2. Communication system (system claim). A system of terminal + client + server in which the terminal (or the client) is registered as the event-notification destination:

• the terminal includes an error determination unit (is the notified event an error?), a notification-destination-determining unit (is the registered destination the server?), and an event notification unit that sends the error event message to the server in that case; and
• the server includes the same reception / transfer / monitoring / notification units as in aspect 1.

In short: the printer only sends error messages to the server when the server is the registered destination, and the server handles monitoring and recovery notification. (Embodiment 1 checks destination type by exchanging a get/get-response message; Embodiment 2 instead embeds a marker in the subscribe request and stores a "notification destination type" field — see FIGS. 19–20.)

3. Communication control method (method claim). The method counterpart, expressed as steps performed across the terminal and server: register a notification destination, determine whether an occurring event is a registered event and whether it is an error event, determine whether the destination is the server, send the error event message to the server, have the server transfer it to the client, monitor for error elimination, and send the recovery message to the client on elimination.

4. Non-transitory computer-readable storage medium (CRM claim). A storage medium storing a program that, when executed, causes a computer to carry out the method of aspect 3.

Notable implementation details (from the detailed description)

• Uses WS-Discovery for device search and WS-Eventing for subscription/notification; the server acts as a proxy for client event registration (FIGS. 7–14).
• The server maintains a proxy event information table (FIG. 14, table 2300) with fields including event-registration-destination URL, event-notification-destination URL, event type, and a "yet-to-be-transmitted error recovery event list" 2305 keyed by the transmitted error-event message ID.
• On receiving an error event, the server stores the message ID; it then periodically polls the printer (FIG. 18, steps S3103–S3108) and, on confirming recovery, sends the recovery event and deletes the entry.
• Prior art cited in the background: Japanese Patent Laid-Open Publication No. 2007-65757.

Uncertainty flags: (1) exact independent claim numerals and precise claim language — not in the retrieved text; (2) any 2026 CAFC/USPTO ex parte or inter partes activity — not found, so I cannot confirm or deny it; (3) the specific Japanese priority application number behind the 2010-08-04 priority date — not shown in the retrieved record.

I'll search for litigation involving US patent 8775878.

No hits yet for this specific patent. Let me run more targeted searches.

Let me run a few more targeted searches to make sure I'm not missing anything.

Litigation Search: U.S. Patent No. 8,775,878

Bottom line: I found no litigation involving U.S. Patent No. 8,775,878.

After searching for the specific patent number (including quoted variants like "8775878", "8,775,878", and "US8775878B2"), the results returned no district court complaints, ITC investigations, PTAB proceedings (IPR/PGR/CBM), or Federal Circuit appeals in which this patent was asserted or challenged. Below is a transparent account of what I checked and the important caveats.

What the searches did and didn't turn up

The searches surfaced several false positives that must not be confused with this patent — they involve different patents that share the digits "878" or "877":

None of these describes U.S. Patent No. 8,775,878 ("Information processing apparatus, communication system, communication control method, and storage medium," Canon Kabushiki Kaisha, inventor Masashi Nishiyama, filed Aug. 4, 2011, granted July 8, 2014).

Search sources consulted and limitations

• General web search for 8775878 litigation / infringement / lawsuit.
• Quoted-number searches ("8,775,878", "US8775878B2").
• Canon-related patent-litigation queries.

I was not able to directly query the paywalled/portal databases you named (Unified Patents litigation portal, PACER, and the CAFC docket) within this session; results came from general web indexing of patent and court documents. A few additional targeted queries were cut off by a tool-step limit.

Recommendation before relying on "no litigation"

Because this patent is a Canon-owned, operating-company portfolio patent covering printer event-notification / device-proxy-server technology (not a typical NPE assertion vehicle), the absence of litigation is plausible. Still, to be certain, I recommend confirming directly against:

1. PACER / CourtListener RECAP — docket search on "8,775,878" and on the patent number field.
2. Unified Patents litigation portal (portal.unifiedpatents.com/litigation) — patent-number lookup.
3. USPTO Patent Trial and Appeal Board (PTAB) — IPR/PGR search for this patent number.
4. USPTO Patent Center / Assignment record for the patent (which shows the Canon assignment from 2011, per the patent text, but no litigation data).
5. CAFC docket for any appeal mentioning the patent.

If you'd like, I can draft the exact query strings for those databases, or attempt further web searches on specific dockets (e.g., Canon as plaintiff/defendant) once the step limit is reset.

Status of any litigation: None identified. Case fields (plaintiff, defendant, jurisdiction, case number, filing date, outcome) cannot be populated because no case was found for this specific patent number.

I'll start by verifying the canonical structured data and checking independent sources for any PTAB activity on this patent.

Let me run additional targeted searches to rule out proceedings that might use different formatting or pairing with the Canon patent.

Let me run final confirmation searches against PTAB/docket aggregators and check for any ex parte reexamination or CAFC activity that could be confused with an AIA trial.

Proceedings overview

Total AIA trial proceedings on file for U.S. 8,775,878: 0. The structured "PTAB proceedings on file" block (the canonical USPTO Open Data Portal list supplied for this task) reports no IPR, PGR, or CBM proceedings ever instituted, denied, or even filed against this patent. There are accordingly no entries for active / claims-invalidated / claims-sustained / settled / institution-denied — every bucket is empty. The bottom-line defensive posture is therefore unusual and worth stating precisely: this is not a "hardened" patent in the sense of having survived an attack — it has simply never been attacked. No claim has been canceled, no claim has been adjudicated valid, and no claim has been tested. For a defendant, that cuts two ways: there is no PTAB win to point to, but there is also no PTAB record, no claim-construction ruling, and no estoppel against you — an IPR remains fully available and unencumbered.

Verification note / conflict flag. The canonical structured block says "no PTAB activity," and my web searches were consistent with that — but I could not complete the planned follow-up queries (a docketalarm/PTAB-E2E number lookup and a reexamination check) because the tool step limit was reached. Every web hit that superficially matched "878" was a different patent and must not be attributed here:

None of these involves U.S. 8,775,878 (Canon K.K.; inventor Masashi Nishiyama; filed 2011-08-04; granted 2014-07-08; "Information processing apparatus, communication system, communication control method, and storage medium").

Proceedings detail

Not applicable — no AIA trial proceeding to report. Because no case number exists, I will not generate the per-proceeding template (petitioner, panel, grounds, FWD). Doing so would require inventing a proceeding number, and the task instructions expressly forbid that ("Do not invent proceeding numbers").

For completeness on the adjacent-but-distinct items a defendant might hear about:

• IPR/PGR/CBM: none for 8,775,878 (canonical data; web searches returned only the false positives above).
• Federal Circuit appeal: none identified. There can be no CAFC appeal of an FWD that does not exist. (The CourtListener/govinfo hits I saw concerned unrelated patents and parties.)
• Ex parte reexamination / reissue: not confirmed. I was unable to complete the dedicated check before the step limit; treat as unknown, not as "none."

Strategic summary

Claim status. Every claim of 8,775,878 — the independent apparatus claim(s) covering the device-proxy-server "reception unit / transfer unit / monitoring unit / notification unit" architecture, and all dependents — is UNTESTED at the PTAB. None is canceled; none has been sustained in an AIA trial. Because there is no patentability adjudication, any validity position you take must be built from scratch. If you are weighing an IPR, note the patent's own framing: the alleged novelty centers on the proxy server monitoring the terminal for error elimination and itself emitting the error-recovery message to the client (see the Summary, first aspect, and FIG. 18/S3101–S3108), against the admitted backdrop of WS-Eventing/WS-Discovery and Japanese Laid-Open Pub. No. 2007-65757. That is a narrow, well-delineated hook for prior-art searching.

Estoppel landscape. There is no § 315(e)(2) estoppel against anyone, because no petitioner has ever obtained an institution decision on this patent. For a defendant now facing assertion, all prior-art grounds remain available — § 102 and § 103, on any reference, with no "reasonably could have raised" bar. There is also no IPR-driven claim construction (no Phillips/BRI record) that a patent owner could use against you, and no Board claim constructions to lock you in. Practically, this makes an IPR a clean-slate option, unburdened by another party's litigation choices.

Pattern signals. No repeat-petitioner pattern (no petitioners at all). No evidence the patent owner has pursued PTAB appeals for this patent (none possible). No defensive aggregator (Unified Patents or similar) appears anywhere in the chain for this number. The only Canon PTAB presence my searches surfaced had Canon on the petitioner side on a different patent — i.e., Canon as an operating-company portfolio enforcer, not a target. Combined with the Google Patents status line "Expired – Fee Related," the picture is of a patent that was never monetized or asserted hard enough to attract a validity challenge.

Caveat on the "absence is a signal" heuristic. The familiar rule of thumb — "well-asserted patents eventually attract IPRs" — is satisfied trivially here: this patent appears never to have been asserted at all (consistent with the earlier litigation summary finding no litigation). So the empty PTAB docket is best read as "this patent has seen little or no enforcement activity," not as "this patent is so strong nobody dared challenge it." Those are different inferences, and the evidence supports the former.

Recommended next steps

1. Treat "no PTAB activity" as the working answer, but harden it at the source. Before relying on it in a defensive strategy memo, confirm directly against:
   • USPTO PTAB E2E / Patent Trial and Appeal Board End-to-End — search by patent number 8,775,878 and by application 13/198,079 (PTAB E2E). The canonical ODP feed is usually current, but a brand-new filing can lag.
   • USPTO Patent Center for this patent — confirm no ex parte reexamination or reissue is pending (the one gap I could not close).
   • CourtListener / RECAP for any CAFC appeal or district-court docket citing the patent.
2. If you are a defendant today: because nothing is canceled, you cannot point to an FWD and say "the asserted claims are dead." Your levers are (a) a fresh IPR on the proxy-monitoring claim (no estoppel, no adverse claim construction), and/or (b) district-court invalidity, with the patent's own admitted prior art (WS-Eventing, WS-Discovery, JP 2007-65757) as the starting point. Note the patent's effective priority date 2010-08-04; the § 102(b)/AIA-art window and the WS-Eventing standards history should be scoped to that date.
3. Watch for the standard lag. If this patent is newly asserted against you, expect any IPR institution decision within ~6 months of filing and an FWD within 12 months of institution (35 U.S.C. § 316(a)(11)). But do not represent to a court or client that any such proceeding exists — today, it does not.
4. Do not cite the look-alike numbers. If a search or an opposing brief throws out "the '878 IPR" (LifeScan/PHC 8,480,878, Hera 7,369,878, etc.), verify the number — those proceedings say nothing about this patent.

Status: no AIA trial proceedings on file for U.S. 8,775,878. The absence is real and, given the apparent lack of any enforcement history, neither surprising nor a strength signal.

I'll research the assignment record for this patent. Let me start with targeted searches.

Let me try more targeted searches on the assignment record and the inventor.

Let me try to access the USPTO assignment record directly and via alternative indexes.

I was unable to complete direct queries against the USPTO Assignment Center portal (the tool step limit was reached, and the portal itself is not retrievable through general web search). I'm therefore building the ownership chain from the authoritative patent text supplied for this analysis — specifically the Google Patents "Legal Events" / reassignment record, which mirrors the same underlying USPTO assignment data — and I flag below exactly what I could and could not verify. Per the operating rules, I won't fabricate reel/frame numbers or correspondents that I could not retrieve.

Inventors

Masashi Nishiyama — sole named inventor.

• Employer at filing: Canon Kabushiki Kaisha (Canon Inc.). The patent names Canon as assignee, and the recorded conveyance is an "ASSIGNMENT OF ASSIGNORS INTEREST" from NISHIYAMA, MASASHI to CANON KABUSHIKI KAISHA. The specification is written entirely around Canon printer/WS-Discovery/WS-Eventing product architecture, consistent with a Canon employee inventor.
• Pattern note: Only one inventor, no departures, and no co-inventor chain — the kind of single-inventor corporate filing that does not exhibit the "all inventors depart within 12 months" fire-sale precursor pattern. No such signal is present.

I did not independently verify Nishiyama's employment history beyond the four corners of the patent.

Original assignee

Canon Kabushiki Kaisha (Canon Inc.) — 30-2, Shimomaruko 3-chome, Ohta-ku, Tokyo 146-8501, Japan.

• Line of business: Diversified imaging/optics/office-equipment manufacturer. The patent is squarely within Canon's core printer/networked-device management business.
• Product embodying the claims: The specification describes a device proxy server mediating WS-Discovery/WS-Eventing between Canon printers and client PCs (FIGS. 1–20). Canon's imageRUNNER/LBP-class network printers and its device-management software are the natural commercial embodiments. I could not independently confirm a specific shipping SKU from the record, but this is an operating-company portfolio patent, not a paper asset.
• Current status: Operating, publicly traded (TYO: 7751). No bankruptcy, dissolution, or divestiture of this patent appears in the record.
• Both the patent front page and the Google Patents event log list "Canon Inc." as original assignee and "CANON KABUSHIKI KAISHA" on the recorded reassignment — these are the same entity; the difference is naming convention, not a transfer.

Assignment timeline

The authoritative patent text (Google Patents legal events) shows exactly one recorded reassignment, plus the routine prosecution/publication events. No post-issuance assignment appears.

• YYYY-MM-DD (executed): not shown in the record / recorded 2011-11-15 — Reel NNNNNN/NNNN: NOT RETRIEVABLE
  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS)
  • Assignor: NISHIYAMA, MASASHI
  • Assignee: CANON KABUSHIKI KAISHA
  • Correspondent of record: Not retrievable from the sources available to me. I could not query the Assignment Center to obtain the recording attorney/firm. I will not guess — Canon's recordings are typically handled by Canon's own IP department or its long-time outside prosecution firms, but the specific correspondent for this reel/frame is unverified.
  • Context: Original inventor-to-employer assignment (standard corporate prosecution assignment), recorded roughly 3 months after the 2011-08-04 filing date. Not a fire-sale, reorg, securitization, or asserter transfer.

Important caveat on completeness: Because I could not reach the Assignment Center directly, I cannot rule out a second recorded instrument (e.g., a confirmatory assignment or a same-family license) that Google Patents' event log might not surface. Based on the sources I could retrieve, only the single 2011-11-15 conveyance exists.

Caveat honored per your constraint: the specific reel/frame and correspondent fields are missing because they were not retrievable — I am reporting that gap rather than filling it with plausible-looking numbers.

Timeline diagram

timeline
    title Ownership of US 8775878
    2011 : Filed by Canon with inventor Nishiyama
         : Assignment recorded to Canon Kabushiki Kaisha
    2012 : Pre-grant publication US20120036403A1
    2014 : Patent issued to Canon
    2032 : Adjusted expiration 2032-09-17

NPE / troll-pattern signals

Note on Signal 8 inverse: although the chain does not end at a defensive aggregator, the practical effect is similar for asserting purposes — an operating company holding its own portfolio patent is the opposite of an NPE posture.

Verdict

Insufficient data — the chain contains only the original inventor-to-employer assignment.

Justification: The only recorded conveyance is the 2011-11-15 assignment from sole inventor Masashi Nishiyama to CANON KABUSHIKI KAISHA; there are no post-issuance transfers, no LLC assignees, no known asserter, and no identified litigation, so no strong NPE signal is present. Because the record consists solely of the original assignment (and because I could not retrieve the reel/frame or correspondent to rule out an unindexed secondary instrument), this falls into the "only the original assignment" category rather than an affirmative "operating-company assertion" finding — there is no evidence of assertion activity either way. If pressed for the character of ownership, it reads as a conventional operating-company portfolio patent that Canon has retained.

Verification link (USPTO Assignment Center, search by patent number 8775878):
https://assignmentcenter.uspto.gov/ — legacy mirror: https://assignment.uspto.gov/patent/index.html

Recommended follow-up to close the gap: a direct Assignment Center query on patent number 8775878 to capture the reel/frame and correspondent of the 2011-11-15 recording, plus a PTAB/IPR and PACER/CourtListener check to confirm the "no litigation" null result. I flag both as not independently completed in this session.

I'll search for the actual prior-art citations of US 8,775,878, since the patent text provided did not include the "References Cited" section.

Let me try to retrieve the actual "References Cited" / "Patent Citations" section for this patent.

The general searches keep returning the same truncated page. Let me target sources that explicitly reproduce the "References Cited" / citation tables.

Prior-Art Analysis — U.S. Patent No. 8,775,878 B2

Important honesty flag up front: I was unable to retrieve the actual "References Cited" / "Patent Citations" table for US 8,775,878 B2 within this session. The authoritative full text you provided (the Google Patents transcription) was truncated and does not include the examiner-cited prior-art list, the "References Cited" section, the front-page U.S./foreign patent citations, or the full claim set. My later searches kept returning the same truncated Google Patents page and unrelated search reports for other patents. Per your operating rules, I will not fabricate citations, dates, or § 102 mappings to fill that gap. Below is what I can state with confidence, what I cannot, and exactly how to obtain the missing data.

1. What I could confirm

The only prior-art reference explicitly named anywhere in the patent record I retrieved is:

Potentially relevant claims under 35 U.S.C. § 102

Proceed with caution here, because I do not have the issued claim language.

• Claim 1 (independent "information processing apparatus"/server claim — inferred, not verified): JP 2007-65757, as characterized in the background, describes the printer storing transmission history and originating the recovery notification. Claim 1 instead recites a separate information processing apparatus (proxy server) that receives the event, transfers it to the client, monitors the terminal for elimination of the error, and sends the recovery message. On that basis, JP 2007-65757 does not appear to anticipate the server-side claim under § 102 — its architecture is the opposite of the claimed one. If anything, it is background art suggesting the problem the invention solves, not the solution.
• Independent "communication system" claim (aspect 2 — the terminal-side error determination unit / notification-destination-determining unit / event notification unit, plus the server units): This is the only claim family where JP 2007-65757 is potentially a § 102 concern, and only for the sub-combination of terminal-side elements (error detection at the printer, sending an error event, and later enabling a recovery notification). Because the system claim requires both terminal-side elements and the proxy-server elements in a single claim, JP 2007-65757 alone would not anticipate it unless it also disclosed the server proxy with transfer-plus-monitoring-plus-notification — which the background does not attribute to it. Its more realistic role is as § 103 background art, not § 102 art.
• Method claim and CRM claim (aspects 3 and 4 — inferred): Same reasoning: these require the proxy-server steps (transfer, monitor, notify), which JP 2007-65757 is not described as performing.

Bottom line on § 102: Based strictly on how this patent itself describes JP 2007-65757, that reference appears to be background/§ 103-type art directed at the problem, and I cannot identify a § 102 anticipation relationship with any claim. This conclusion is provisional and could change if the reference's full text reveals a proxy/server architecture.

2. What I could NOT retrieve (and will not invent)

• The complete "References Cited" list: U.S. Patent Documents, Foreign Patent Documents, and Other Publications cited on the face of US 8,775,878 B2.
• Any U.S. patent or published application cited by the examiner as anticipatory or obviousness art.
• The "Cited By" list (forward citations) — not prior art, but useful context.
• The exact independent/dependent claim numbering and language, which is required for a rigorous § 102 element-by-element mapping.

I searched for the citation table via multiple query formulations (quoted patent-number variants, "References Cited," "Patent Citations," FPO/Google Patents/Patents-Review/Espace-net-style sources). None returned the citation list for this number; several returned search reports and reference lists belonging to unrelated patents (e.g., WO2016094296, EP3211837, EP4295956, JP2017530890), which I am deliberately not presenting as citations of US 8,775,878.

3. How to obtain the authoritative citation list (recommended)

To complete a defensible § 102/§ 103 analysis, pull the primary-source record:

1. USPTO Patent Public Search (ppubs.uspto.gov) — search 8775878; open "References Cited" and "Claims." This is the authoritative examiner-facing record.
2. USPTO Patent Center / Patent Application 13/198,079 — the file wrapper contains the IDS/SB-08 and PTO-892 (Notice of References Cited), i.e., exactly which references the examiner actually applied and where.
3. Google Patents (patents.google.com/patent/US8775878B2/en) — the "Patent Citations" and "Cited By" tables (which my fetches could not surface in text).
4. FreePatentsOnline / Justia Patents / Espacenet — for the same face-page citation list and INPADOC family data.
5. JPO J-PlatPat — for the full Japanese text of JP 2007-65757 (to verify its dates and whether it discloses any server/proxy element).

4. Explicit uncertainty statement

• I have one confirmed reference (JP 2007-65757) and zero confirmed U.S. patent citations for US 8,775,878 B2.
• I did not verify JP 2007-65757's exact publication date, applicant, or substantive disclosure; my description of it is derived solely from how US 8,775,878 characterizes it.
• I did not verify claim numbering; the claim mapping is inferred from the four "aspects" recited in the specification.
• Any statement here that a reference "anticipates" a claim is a provisional, best-effort view, not a formal invalidity opinion.

If you can supply the front-page "References Cited" list (or grant additional search steps), I will produce the full per-reference table — citation, publication/filing date, description, and claim-by-claim § 102 analysis — exactly as requested.

I'll analyze obviousness under § 103 for US 8,775,878. First, let me gather the prior-art references from the Google Patents page (cited references, "Similar Documents," and the prior-art keywords) plus the key admitted prior art.

Excellent — I've confirmed the key admitted prior art (JP 2007-65757) and the WS-Eventing architecture. Let me now pull the actual "Prior Art" citation lists from the Google Patents page and look for the specific proxy/event-notification references I'd expect to be cited.

Obviousness Analysis — U.S. Pat. No. 8,775,878 B2 under 35 U.S.C. § 103

Scope note and caveats (read first). The full claim set was not in the text I retrieved (see the earlier "Patent summary" section, which flags this). I therefore analyze the limitations as recited in the specification's four "aspects," which correspond to the four independent claims (apparatus / system / method / CRM). Additionally, I could not retrieve the complete machine-readable "References Cited" (patent citations + non-patent citations) list from the Google Patents page before my tool budget expired; the reference set below is the one I could verify from the page's cited material and the surrounding prior-art section. Anything I did not verify is labeled as such. I do not invent reference numbers or holdings.

1. Governing law and framing

• Pre-AIA § 103 applies. The application was filed 2011-08-04 (before the Mar. 16, 2013 AIA change), claiming priority to 2010-08-04. Prior art therefore qualifies under pre-AIA § 102(a)/(b)/(e). The critical date for § 102(b) printed publications is 2010-08-04.
• POSITA. A person having ordinary skill in the art here is a network/software engineer with ~2–4 years' experience with (i) Web-services protocols (SOAP, the WS-* stack), (ii) network device management, and (iii) printer/MFP status monitoring — or a bachelor's degree in CS/EE plus about two years of such experience. This is a well-trodden engineering field, which matters to the KSR "predictable results" analysis below.

2. The limitations that must be met

Nothing in the description suggests any of these limitations carries a special construction; all are functional and are implemented with conventional Web-services messaging (WS-Eventing / WS-Discovery) plus ordinary program logic — which is itself an admission of the ordinary skill level.

3. The prior-art reference set

3.1 JP 2007-65757 (Kyocera Mita) — the applicant's own admitted prior art

• Title: 「ネットワーク機器のエラー通知装置およびエラー通知プログラム」 ("Error notification apparatus and error notification program for a network device").
• Published: 2007-03-15; appl. 特願2005-247773, filed 2005-08-29; inventor Hirokazu Yamamoto (山本 宏和); applicant Kyocera Mita (京セラミタ). Source: https://patentimages.storage.googleapis.com/08/5e/d6/7cae25110fea00/JP2007065757A.pdf
• Verified disclosure (abstract + claim 1):
  • 情報チェック手段 11 — checks whether an information-acquisition request from PCs 1–5 to printer 7 is an error-information acquisition request (i.e., it intermediates client↔printer traffic and detects error-related requests).
  • 記憶手段 15 + 履歴作成手段 13 — when an error-information request is detected, creates/updates an error information acquisition request history associated with the requesting PC's address and stores it in the storage means. (Claims 2–3: the history includes the PC address, request count, request time, and inter-request interval.)
  • 通知手段 17 — "when an error occurrence or an error-clearing state occurs in the printer 7," notifies the PCs that made the error-information request of the error-occurrence or error-clearing information based on the stored history.
  • Stated objective: 「プリンタに係るエラー発生/解除状態の通知を必要とするパソコンに対し、自動的、確実に通知できるようにする」 — to automatically and reliably notify the PCs that need notification of printer error occurrence/clearing.
• Why this matters: JP 2007-65757 discloses nearly the entire conceptual core of the challenged invention: an intermediary network apparatus that (a) tracks which clients care about a device's error state, (b) detects both error occurrence and error clearance at that device, and (c) sends the clearing/recovery notification to those clients. The intermediary (not the printer) holds the state.
• Critical observation for the attacker: the specification's stated distinction over this reference is that "an inexpensive printer … makes it difficult for the printer to store information on the history of transmission of error event messages as disclosed in Japanese Patent Laid-Open Publication No. 2007-65757." But JP 2007-65757's history is stored in the error-notification apparatus's storage means 15 (it is a network-side element in claim 1), not in the printer. That characterization is at least contestable, and if the reference's history is on the network side, the patent's asserted point of novelty over it largely collapses. (Flagged: I verified the claim/abstract text; I did not obtain a certified translation of the full JP2007-65757 description, so a human translator should confirm where storage means 15 physically resides.)

3.2 WS-Eventing (W3C; Microsoft/BEA/TIBCO)

• Sources: W3C WD 2009-06-25 (https://www.w3.org/TR/2009/WD-ws-eventing-20090625/), WD 2009-12-17, the 2004 Microsoft/BEA/TIBCO release, and the SOA-book summary (https://thomaserl.com/wp-content/uploads/2017/09/Erl_SOABook2_Ch07-2.pdf).
• Verified disclosure:
  • A subscriber registers interest (a subscription) with an event source; notifications are pushed to the event sink; the message enables filters (which event types to receive), expiry, and renew/unsubscribe.
  • Squarely on point, the specification states its requirements include: "Define how one Web service can subscribe on behalf of another", "Define how an event source delegates subscription management to another Web service", and "Support complex eventing topologies that allow the originating event source and the final event sink to be decoupled" — implemented through an intermediate "subscription manager." (The SOA-book excerpt: "intermediate services, known as subscription managers, optionally can be used…"; the event source "delegates" subscription management.)
• Why this matters: WS-Eventing supplies exactly the missing pieces of Ground 1 — reception of an event message and forwarding of that message to the ultimate client, effected through an intermediary that subscribes on the client's behalf. This is the "reception unit + transfer unit" of claim 1 (aspect A), and the standard's own architecture is the "device proxy server."

3.3 WS-Management / WS-Notification (pull delivery)

• Source (verified excerpt): Microsoft Learn, "Web Services architecture and eventing specifications," https://learn.microsoft.com/it-it/previous-versions/dotnet/articles/ms996441(v=msdn.10)
• Verified disclosure: WS-Management defines a "pull" delivery mode in which "the producing service maintains a logical queue of events so that the subscriber can poll for notifications on demand"; the polling is performed using WS-Enumeration with an enumeration context returned in the subscription response. WS-Notification likewise provides notification-broker patterns.
• Why this matters: this supplies the "monitor whether the error has been eliminated … at predetermined time intervals" (FIG. 18, poll loop S3101–S3108) as a known, standardized alternative to push delivery — i.e., the polling/monitoring element is routine and known.

3.4 US 2010/0198967 A1 — "Image forming apparatus, management apparatus, and management system…"

• Source: https://patentimages.storage.googleapis.com/f6/c4/5b/9fe543499f07ac/US20100198967A1.pdf
• Verified disclosure: a management system that receives error/failure event information from image forming apparatuses, dispatches service engineers, and explicitly works with "event information including failure information" and correlating event IDs; it discusses storing previously transmitted information and only transmitting on difference to reduce storage/bandwidth loads.
• Why this matters: secondary evidence that (i) reporting printer error events to a central management apparatus over a network, and (ii) keying error records by an event identifier to track state, were known. Supports the "yet-to-be-transmitted error recovery event list 2305" keyed by message ID.
• ⚠️ Date caveat: I did not verify this reference's exact publication date (its number places it around Aug. 2010, which may fall after the 2010-08-04 priority date). If it does not predate the invention, it would need to qualify as § 102(e) art via its earlier US filing date. Verify before relying on it as primary art.

3.5 EP 1809004 A2 — "Managing network-enabled devices"

• Source: https://patents.google.com/patent/EP1809004A2/en (published 2007)
• Verified disclosure (abstract): a network device manager with an event handler module that communicates with network devices; a Manager Module "(MM) issues a service request of a network device in response to receiving an event notification"; and users can "define rules … to be performed upon the occurrence of a network event."
• Why this matters: an intermediary manager that subscribes to device events and acts on them per rules is the "server sits between device and client" architecture; it also supports claim-2-type logic where the manager decides how to handle an event.

4. Grounds of rejection / invalidity

Ground 1 — Claim 1 (aspect A) obvious over JP 2007-65757 in view of WS-Eventing

Motivation / rationale (KSR):

1. Same field, same problem, same solution. Both references address notifying the right client PCs of an error at a networked printer. JP 2007-65757 expressly seeks to automatically and reliably notify the PCs that need error occurrence/clearing information — i.e., its stated objective is precisely the patent's stated objective ("make it possible to confirm an error recovery event").
2. Standardization / interoperability. Replacing JP 2007-65757's bespoke notification with WS-Eventing — the very protocol the patent's own background treats as the environment — is the predictable use of a known standard for its intended purpose, yielding nothing more than expected results.
3. Architectural need already recognized by the standard. WS-Eventing's subscription-manager/"subscribe on behalf of another" mechanism is a designed-for role; a POSITA using WS-Eventing for printer eventing would naturally place the intermediary at the subscription-manager position to relay notifications.
4. Addresses the admitted hardware constraint. Because the printer is resource-constrained (the patent's own premise), locating monitoring/recovery logic at the network intermediary — as JP 2007-65757 already does — is the obvious design choice.

Ground 2 — Claim 2 (aspect B, system) obvious over JP 2007-65757 + WS-Eventing (+ WS-Discovery)

The added terminal-side limitations are met as follows:

Motivation: once the intermediary is the WS-Eventing event sink (Ground 1), the printer must send error events there; distinguishing error events from job-state events is a trivial, previously-known categorization (admitted in the background). Embodiment 2's "notification destination type" field is a routine programming expedient over Embodiment 1's get/getResponse handshake — an obvious substitution of one known technique for another with predictable results (MPEP 2144.04).

Ground 3 — Claims 1/3 (aspects A/C) further obvious over JP 2007-65757 + WS-Eventing + WS-Management (pull delivery) for the periodic-monitoring limitations

To the extent the monitoring unit is said to require periodic polling (FIG. 18, S3103–S3108: "waits over a predetermined time period (fixed time period)"), WS-Management's pull delivery mode discloses polling a device "on demand" while the source "maintains a logical queue of events." Selecting pull vs. push is a known design trade-off (latency vs. resource use) — an obvious choice with predictable results. JP 2007-65757's history/interval fields (claim 2: "要求時刻および又は前回要求からのインターバル期間") likewise evidence periodic monitoring.

Ground 4 — Alternative/supplemental: EP 1809004 A2 as the intermediary

EP 1809004 A2 discloses a manager module that issues a service request/action in response to receiving a device event notification under user-defined rules. This maps onto the monitoring→recovery-notification chain (server receives error event, then acts — here, queries the printer and emits a recovery notification). It is useful as a secondary reference to reinforce that an intermediary reacting to device events was known, and it independently motivates the "server between device and client" topology.

5. Dependent claims (analysis by likely subject matter)

Because I could not verify the exact dependent-claim wording, I address the features the description emphasizes:

• "Yet-to-be-transmitted error recovery event list" keyed by message ID (FIG. 14, 2305). JP 2007-65757 stores an error-information-request history (associated with client addresses and request counts/times) to drive later error-clearing notifications; US 2010/0198967 A1 correlates error records by event ID. Storing the transmitted error event's message ID in a pending-recovery list is the predictable application of these known data-structures to the proxy context — obvious.
• Persisting state in the server's hard disk vs. the printer's volatile RAM. A pure design choice driven by the admitted hardware limitation; no unexpected result.
• "Predetermined time period" polling (S3108). Routine optimization; obtainable by ordinary experimentation (KSR; MPEP 2144.04).
• WS-Discovery probe/probe-match search (FIGS. 7–10). Standardized discovery; the patent's background names WS-Discovery (web service dynamic discovery) itself, so the search function is admitted art.
• Embodiment 2's destination-type field (FIGS. 19–20). Obvious substitution for Embodiment 1's handshake, and it produces only the expected benefit (fewer steps, improved performance).

No secondary considerations appear available. The only asserted advantage — "confirm an error recovery event" on a low-cost printer — is exactly what JP 2007-65757 already achieves ("自動的、確実に通知," automatically/reliably notifying error occurrence and clearing). There is no evidence in the record of unexpected results, long-felt unmet need (the reference solves the same need), industry praise, or licensing nexus. Without a nexus to a specific claimed feature, any such argument should fail.

6. Where the patent owner will push back (and why it likely fails)

1. "JP 2007-65757 doesn't transfer the printer's event message; it generates its own notification." True for the literal "transfer" step — which is precisely why WS-Eventing is combined in. WS-Eventing supplies relay-through-an-intermediary.
2. "JP 2007-65757's history must be kept in the printer, which the invention avoids." As noted in §3.1, claim 1 of JP 2007-65757 places the history in the error-notification apparatus (a network-side device), so the premise is contestable; and even accepting the patent owner's reading, placing that logic in the proxy is the obvious response to the admittedly constrained printer.
3. "The invention monitors after the error event message is forwarded, enabling recovery confirmation." JP 2007-65757 monitors/detects error→clearing transitions and notifies interested clients automatically and reliably — the same monitoring-plus-notification concept.
4. "Different protocol/architecture." Not a patentability argument; the claims are functional and read on the disclosed primitives (receive/forward/monitor/notify).

7. Bottom line

• Claim 1 (apparatus) is very likely obvious over JP 2007-65757 in view of WS-Eventing (and, for periodic polling, in further view of WS-Management pull delivery). JP 2007-65757 provides the error-occurrence/elimination monitoring and recovery-notification to interested clients from a network intermediary; WS-Eventing provides reception and client-side forwarding via a subscription manager that "subscrib[es] on behalf of another."
• Claim 2 (system) is obvious over the same combination: the printer-as-event-source sending error events to the registered proxy destination, with error/non-error discrimination, is admitted background categorization plus WS-Eventing routing.
• Claims 3–4 (method / CRM) fall with claim 1–2 as their direct method and medium counterparts; the dependent features (polling interval, message-ID tracking list, discovery) are routine and supported by JP 2007-65757 and the WS-* standards.
• Motivation to combine is strong and multi-sourced: (a) same field and same stated problem; (b) use of a published standard (WS-Eventing) for its intended purpose; (c) the standard itself contemplates the intermediary/subscription-manager role; (d) the admitted resource constraint on the printer makes offloading to the intermediary the natural design choice.

Overall invalidity risk assessment: HIGH for the independent claims as described, with the most dangerous single combination being JP 2007-65757 + WS-Eventing, both of which predate the 2010-08-04 priority date (§ 102(b) art).

8. Verification gaps to close before relying on this analysis

1. Exact claim text and claim numbering — retrieve the issued claims of US 8,775,878 (I analyzed the specification's four "aspects," not the verified claim language). This is the single most important gap.
2. The complete Google Patents "References Cited" list (US and foreign patent citations + non-patent literature) — I verified only a subset; additional cited references could strengthen or supplement these grounds.
3. Certified translation of JP 2007-65757 — confirm where storage means 15 resides and the full scope of 通知手段 17, which drives Ground 1's strongest argument.
4. Publication/priority date of US 2010/0198967 A1 — confirm whether it qualifies under § 102(a)/(b) or only § 102(e) relative to 2010-08-04.
5. The specific Japanese priority application behind 2010-08-04 (not shown in the retrieved record) — needed to fix the effective filing date precisely.
6. Confirm the WS-Eventing version(s) to cite as § 102(b) art (the 2004 Microsoft/BEA/TIBCO release is safely before the critical date; the 2009 W3C drafts are within the grace year and better used as § 102(a) art).

(Nothing above should be treated as a legal opinion or as a representation that any ground has been adjudicated; no PTAB or court proceeding on this patent was identified in the earlier sections.)