US 8775582

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

Let me run additional targeted searches to confirm there is no distinct 2026 CAFC activity for this specific number.

Search results summary

Important caveat on the CAFC "2026 docket" portion: I found no CAFC 2026 (or any) appellate docket activity for US 8,775,582. My searches surfaced several unrelated patents that happen to end in "558," and I want to flag these as not this patent:

• Quanergy Systems, Inc. v. Velodyne Lidar USA, Inc. — concerns Velodyne's different '558 patent (a LiDAR patent). Not US 8,775,582.
• The Trustees of the University of Pennsylvania v. Eli Lilly (E.D. Pa. 2:15-cv-06133) — a biotech '558 patent. Not this patent.

My search results did not return a live USPTO PatentCenter/Public PAIR record page or a CAFC docket entry for 8,775,582; the substantive content below is grounded in the full patent text (Google Patents, fetched 2026-09-28), which is the authoritative source I was given. Treat the "no litigation found" statement as based on search coverage, not a certified litigation search.

Bibliographic data for US 8,775,582 B2

Abstract (verbatim)

"A communication device setting apparatus is arranged to register setup information in a communication device connected to the communication device setting apparatus via a communication network. In the communication device setting apparatus, a device setting unit recognizes an access from the communication device upon power up of the communication device, acquires setup information, which is specific to the communication device and contains a MAC address of the communication device, from list information pre-recorded in the communication device setting apparatus, and performs a setting process to set the acquired setup information in the communication device. A setting management unit detects an end of the setting process performed by the device setting unit, changes the list information based on the setup information having been set in the communication device after the end of the setting process, and manages the communication device according to the changed list information."

Plain-language overview of the independent claims

Claim 1 — Apparatus (independent; the broadest claim).
A communication-device setting apparatus (a hardware-processor-based tool, e.g. a factory floor PC) that provisions setup data into a device (e.g. a set-top box) over a network. Three cooperating units:

• Device setting unit — sees the device "phone home" when it powers up, pulls that device's specific setup info (including its MAC address) out of a pre-stored list, and writes it into the device.
• Setting management unit — notices when that write finishes, updates the list to reflect what was actually written, and manages the device based on the updated list.
• Key information generating unit — fetches key information using the corresponding key file name in the list, encrypts it; the setup info written into the device contains that encrypted key. Notably, after the write completes, the encrypted key is moved from a "writing encryption key folder" to a "written encryption key storage folder" without changing the key file name.

Claim 6 — Method (independent).
The same overall flow as claim 1, expressed as method steps performed by the device setting unit, setting management unit, and key information generating unit (recognize power-up access → acquire setup info with MAC address from the pre-recorded list → write it → detect completion → update list → manage accordingly → acquire and encrypt key info → move the encrypted key file between folders without renaming).

Claim 9 — Non-transitory computer-readable recording medium (independent).
A non-transitory computer-readable medium storing a program that, when executed, causes a computer to carry out the method of claim 6.

Claim 10 — Communication system (independent).
A system combining (a) the apparatus of claim 1 and (b) the communication device itself, which has a hardware control unit that: on power-up, requests the setup info from the setting apparatus; receives command information from the apparatus; executes that command info to access/retrieve the setup info from a predetermined recording area of the apparatus's storage; and outputs a message indicating the recording of setup info in the device has ended.

Claim 11 — Method (independent in form; dependent on claim 6). Adds the device-side steps (request on power-up, receive command information, execute it, etc.). Note: the excerpt of claim 11 in the provided text is truncated mid-sentence ("executing, by the control unit of th…"), so I cannot fully characterize its closing limitations. Claim 12 was likewise not included in the excerpt.

Dependent claims (for completeness)

• Claim 2 (dep. 1) / Claim 7 (dep. 6): key information contains at least one of an HDCP key and a Marlin key.
• Claim 3 (dep. 1) / Claim 8 (dep. 6): the device setting unit generates command information causing the device to receive the setup info and outputs it to the device.
• Claim 4 (dep. 1): the apparatus stores address information identical to address information pre-registered in the device that the device uses to reach an HTTP server on the network (i.e., it impersonates the HTTP server so the device auto-connects on power-up).
• Claim 5 (dep. 1): the communication device is one of a set-top box, television set, personal computer, personal digital assistant, or game machine.

Key technical points from the specification

• Problem addressed: conventional manual writing of MAC addresses and key information (e.g., per WO 2003/101040) required a human operator to handle confidential device-specific data, risking input errors, illegal copying, and management complexity.
• Core insight: the setting apparatus is given the same IP address as the HTTP server the device would normally contact on power-up, so the device automatically connects to the setting apparatus instead and receives provisioning with no special device-side control process — the device behaves "as if" it had executed a normal command from the HTTP server.
• Four stated functions: (1) automatic writing of MAC address + key info; (2) automatic encryption of key info; (3) automatic management of setup info via a management list and folder moves; (4) storing HTTP-server-identical address information.
• Management list (FIGS. 7A/7B): pre-process list has "MAC address / HDCP key file name / Marlin key file name / writing state"; the in-process list adds "factory name / date of writing / serial number."

Uncertainty flags

• I could not confirm a USPTO PatentCenter record or any CAFC/Federal Circuit docket for 8,775,582 from search results; the two "558" hits returned are demonstrably different patents. If a formal litigation/docket check is required, that should be run directly against USPTO PatentCenter and the CAFC docket system.
• Claims 11 and 12 are truncated in the supplied text, so my claim descriptions for those are partial.

I'll search for litigation records involving US patent 8775582.

Let me run more targeted searches to rule out confusion with other "558" patents.

Let me try additional targeted searches to be thorough.

Search result: No known litigation involving US 8,775,582

I searched for litigation records keyed specifically to US 8,775,582 (title: "Communication device setting apparatus, communication device setting method, and recording medium"; applicant/current assignee Mitsumi Electric Co., Ltd.; inventors Hirokatsu Miyamoto and Minoru Kataoka; filed 2011‑09‑21; granted 2014‑07‑08). I found no district court case, ITC Section 337 investigation, or PTAB proceeding in which this patent was asserted or challenged.

What I confirmed

The "Expired – Fee Related" status indicates the patent lapsed for failure to pay maintenance fees. That is factually consistent with a patent that was never commercialized through litigation, and it strongly suggests the patent is no longer an enforceable litigation asset.

Important caveat on false positives

Searches for the bare strings "8775582," "8,775,582," or "'582"/"'558" return a large volume of unrelated documents, which I excluded. In particular, do not conflate US 8,775,582 with any of the following, all of which appeared in results but are different patents:

• US 8,775,833 – asserted by Daedalus Prime LLC v. Samsung Electronics Co., Ltd., [Samsung Electronics America, Inc.](/litigations/by-plaintiff/Samsung%20Electronics%20America%2C%20Inc.), and Taiwan Semiconductor Manufacturing Co. (E.D. Tex., No. 2:22‑cv‑00352, filed 2022‑09‑12) and in related D. Del. actions.
• US 7,257,582 – one of the "cloud patents" asserted by Intellectual Ventures I LLC / Intellectual Ventures II LLC v. American Airlines, Inc. (E.D. Tex., Sherman Div., complaint filed 2024‑11‑02).
• The Qualcomm envelope‑tracking "'558" patent litigated in ITC Inv. No. 337‑TA‑1065 (Apple v. Qualcomm) and the Quanergy "'558" patent challenged in a PTAB petition — neither is US 8,775,582.
• An SEC EDGAR Form 424B2 filing carrying the unrelated internal identifier "8775582."
• AU 8,775,582 A – an unrelated Australian patent document.

Confidence and limitations

• High confidence that no litigation is publicly indexed under US 8,775,582 specifically. Assignee Mitsumi Electric is a passive Japanese component supplier with no meaningful U.S. patent-assertion history for this type of patent (device provisioning of MAC addresses/DRM keys during manufacturing), and the patent's fee‑lapsed status makes assertion economically implausible.
• Caveats: My searches relied on public web indexes rather than a direct, authenticated PACER docket query or a subscription database (Unified Patents Portal, RPX Insight, Docket Alarm, Lex Machina). Sealed cases, unindexed state‑law/contract disputes, and foreign proceedings could exist and would not surface in this search. Note also that the two dates supplied to me in this session (April 26, 2026 and September 28, 2026) are inconsistent; litigation filed very recently may not yet be indexed regardless of which date is correct.

Recommended verification steps

To confirm the negative result conclusively before relying on it:

1. USPTO Patent Center / Assignment records for application 13/238,486 – check for recorded litigation-related assignments (indication of a sale to an NPE).
2. Unified Patents Litigation Portal (portal.unifiedpatents.com/litigation) – filter by "8,775,582" exactly.
3. CourtListener / PACER docket search on the patent number in the "Nature of Suit: 830 Patent" category.
4. PTAB (ptacts.uspto.gov) search for IPR/PGR/CBM petitions naming this patent.

Bottom line: Based on the searches performed, there are no known litigation proceedings involving US 8,775,582. If no case exists, the appropriate attorney work product statement is simply: "No litigation known as of the search date." This is not legal advice and should be confirmed against primary docket sources.

I'll verify the proceeding list against public sources before drafting.

Search results so far are hitting unrelated patents (7,731,558) and a coincidental SEC filing ID. Let me run more targeted queries.

PTAB / AIA Trial Proceedings — US 8,775,582 B2

"Communication device setting apparatus, communication device setting method, and recording medium"
Assignee of record: Mitsumi Electric Co., Ltd. · Inventors: Hirokatsu Miyamoto, Minoru Kataoka
Priority date: 2010-10-01 · Filed: 2011-09-21 · Granted: 2014-07-08

Proceedings overview

Total AIA trial proceedings on file: 0. The USPTO Open Data Portal returned no IPR, PGR, or CBM proceeding for US 8,775,582 as of the most recent ingest, and targeted web searching surfaced no AIA trial petition, institution decision, Final Written Decision, or Federal Circuit appeal naming this patent. There is therefore no breakdown by status to report — no claims invalidated, none sustained, none settled, no institution denials. Defensive posture: the patent is untested at the PTAB, not "hardened." Nothing about this patent has been validated or narrowed by the Board; the absence of proceedings reflects the patent's apparent lack of commercial assertion, not its strength.

Important caveat on the scope of this finding. My confidence that no AIA trial exists is moderate-to-high, not absolute. The web searches I ran returned only false positives — other patents whose numbers or specifications coincide (e.g., U.S. 7,731,558 in IPR2013-00120; U.S. 8,862,757 in an ex parte reexam; and an unrelated "’582 patent" concerning parallel processing asserted against American Airlines). One search also returned a coincidental SEC filing whose internal identifier is "8775582" (Goldman Sachs, Form 424B2). None of these involve US 8,775,582. Anyone relying on this memo should confirm the zero count directly against PTAB E2E / Patent Center before treating it as dispositive.

Proceedings

No proceedings to report. Per the task's default and the ODP structured data, the correct entry is:

No AIA trial proceedings on file

• Type: N/A
• Filed: N/A
• Status: No PTAB activity indexed
• Judge panel: N/A
• Petition grounds: N/A
• Institution decision: N/A
• Final Written Decision: N/A
• Settlement / termination: N/A
• Appeal: N/A
• Defensive value: A defendant cannot point to a cancelled claim or an estoppel-bearing FWD. The patent's validity has never been tested in an AIA trial, so its claim scope (including claim 1's hardware-processor device-setting/setting-management/key-encryption combination) remains fully intact as issued.

Strategic summary

Claim status. Because no AIA trial has ever been instituted, all 12 claims of US 8,775,582 stand exactly as issued. Nothing is canceled, nothing is confirmed-as-patentable-by-the-Board, and nothing has been narrowed by certificate. The claims are "untested," not "sustained." For a defendant, that cuts both ways: there is no free invalidity judgment to cite, but there is also no PTAB record in which the patent owner successfully defended the claims — meaning the Board has never credited the patent owner's claim-construction or validity arguments, and there is no IPR-driven claim construction to constrain the patent owner in district court.

Estoppel landscape. No AIA trial means no § 315(e)(2) estoppel exists against anyone. Any defendant is free to file a fresh IPR or PGR on any ground and any art, subject only to the ordinary § 325(d) and Fintiv-style discretion and to the § 315(b) one-year bar running from service of an infringement complaint. Practically, the entire prior-art universe is unencumbered: no ground has been "raised or reasonably could have been raised" before the Office by anyone. Conversely, there is no petitioner-funded invalidity work product to borrow.

Pattern signals. None. There is no repeat petitioner, no patent-owner PTAB appeal history, and no defensive aggregator (e.g., Unified Patents) in the chain. The patent is a manufacturing/production-line tooling disclosure — a factory-side apparatus that auto-writes MAC addresses and DRM keys (HDCP, Marlin) to set-top boxes on a conveyor line — held by a Japanese components manufacturer, and it shows no signs of having been asserted in litigation that would attract an IPR challenger. Note also the prosecution-history signal: the claims as granted recite a "hardware processor," "hardware control unit," and "non-transitory" medium, language typical of post-Alice / § 101-driven amendment — which may matter to an eligibility defense even though it is irrelevant to the PTAB count here.

Recommended next steps

1. Since no PTAB activity exists, say so plainly in any defense memo — and treat it as a signal, not a shield. Well-asserted patents eventually attract IPRs; a nine-plus-year-old patent with zero AIA filings is more consistent with "never meaningfully asserted" than "too strong to challenge." That materially lowers the expected cost of an IPR-based defense if a demand letter appears.

2. Before relying on this memo, confirm the zero count and check the patent's live legal status. Google Patents lists US 8,775,582 as "Expired – Fee Related" with an adjusted expiration of 2031-11-08, which on its face suggests the patent lapsed for failure to pay maintenance fees. If that is accurate, it may be dispositive of an assertion entirely (no liability for post-lapse conduct), which is a far more powerful defense than any IPR. Verify maintenance-fee and expiration status at USPTO Patent Center and confirm whether any petition to revive or intervening rights issue exists. Treat the Google Patents legal-status line as a lead, not a legal conclusion.

3. If you do file an IPR, note there is no institution decision, no FWD, and no appeal to cite — you would be the first mover. Calibrate the § 325(d) and § 314(a) discretion arguments accordingly, and check the § 315(b) one-year clock from your own service date.

4. Ground-truthing links: PTAB matters are searchable at PTAB E2E (https://ptacts.uspto.gov/ptacts/) and decisions at the USPTO PTAB Decisions portal; patent status at Patent Center (https://patentcenter.uspto.gov/). For any litigation or appeal that may exist outside the AIA-trial index, check CourtListener (https://www.courtlistener.com/) for the patent number. My searches of those sources surfaced no proceeding — but I could not complete a full docket-level sweep, so an independent confirmation pass is warranted before this is relied upon.

No proceeding number, judge name, FWD disposition, or appeal docket has been stated here because none was found; nothing in this memo should be read as inventing one.

I'll research the assignment record for US 8,775,582, starting with the USPTO Assignment Center and related sources.

Let me search for the assignment chain and the corporate fate of Mitsumi Electric.

Let me dig for the specific reel/frame of the original assignment and any post-issuance records.

I was able to retrieve the original assignment event and the corporate fate of the assignee, but my search coverage did not surface a Public Assignment Search record page with a specific reel/frame for this patent, and I hit the tool-step limit before I could pull the record page directly. I will not fabricate reel/frame numbers — where I could not confirm one, I say so explicitly.

Assignment & Ownership Analysis — US 8,775,582 B2

Inventors

Pattern check: The typical "all inventors depart within 12 months → fire-sale" red flag is not determinable from the sources I could reach. I did not find any evidence of inventor departures, and I did not find either inventor surfacing as an inventor on later, separately-owned US filings (absence of evidence, not evidence of absence). I could not confirm the inventors' individual residential addresses; other contemporaneous Mitsumi assignments list inventors at Tama-shi, Tokyo, which is consistent with the Mitsumi headquarters address (2-11-2 Tsurumaki, Tama-shi, Tokyo 206-8567), but I will not attribute that address to these two individuals without a direct record.

Original assignee

Mitsumi Electric Co., Ltd. (also styled "MITSUMI ELECTRIC CO., LTD."), 2-11-2, Tsurumaki, Tama-shi, Tokyo 206-8567, Japan.

• Primary line of business: design and manufacture of electrical machinery and electronic components — semiconductors, optical devices, mechanical parts, high-frequency components, and power-source parts. It was a component supplier, not a consumer-platform company.
• Did it ship a product embodying the claims? Unclear / probably indirectly. The apparatus claims (claim 1) cover a factory provisioning tool that writes MAC addresses and DRM keys into devices — i.e., a manufacturing-line instrument, plus a method for using it. Mitsumi plausibly practiced this internally on its own assembly lines, and the specification expressly frames the invention as applicable to "the manufacturing processes and maintenance of communication devices." I found no evidence Mitsumi sold this setting apparatus as a standalone commercial product, and no evidence of a consumer STB bearing this patent. Treat "shipped a product" as unconfirmed.
• Current status: Operating, but no longer independent. On January 27, 2017, Minebea Co., Ltd. and Mitsumi Electric Co., Ltd. completed a business integration by share exchange (ratio 1 : 0.59), making Mitsumi a wholly-owned subsidiary of Minebea; Minebea then renamed itself MinebeaMitsumi Inc. (Mitsumi remained a corporate entity and is slated to be the surviving operating entity in the group's planned holding-company restructuring). So the legal owner of record can still be Mitsumi Electric Co., Ltd., while the economic owner is MinebeaMitsumi Inc. Not in bankruptcy; not dissolved.

Assignment timeline

Caveat up front: The only assignment event appearing in the Google Patents legal-events record for US 8,775,582 is the original inventor→Mitsumi assignment. I did not locate any post-issuance assignment (no Change of Name, Merger, Security Agreement, or transfer to a third party) in the sources I could retrieve. I also could not confirm the reel/frame number for the recorded assignment; the USPTO Assignment Center record page did not surface in my search results. The reel/frame is therefore left as [not confirmed] rather than guessed.

• Executed [date not confirmed — likely on/near the 2011-09-21 filing date] / recorded 2011-09-21 — Reel [not confirmed] / Frame [not confirmed]
  • Conveyance: Assignment (recorded by Google Patents as "reassignment"; document stated as "ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS)")
  • Assignor: Hirokatsu Miyamoto; Minoru Kataoka (joint inventors)
  • Assignee: MITSUMI ELECTRIC CO., LTD.
  • Correspondent: [not confirmed] — I could not retrieve the correspondent of record (attorney/agent) for this specific recording. For context, contemporaneous Mitsumi Electric US assignments (2015 filings) were filed under Customer Number 77464 and the assignee address 2-11-2, Tsurumaki, Tama-shi, Tokyo 206-8567 Japan, but I cannot attribute that customer number to this 2011 recording without the record page, so I do not treat it as a recurrence finding.
  • Context: Original assignment / obligation-to-assign at invention — the inventors conveying rights to their employer. Nothing in this link is a fire-sale, reorg, securitization, or transfer-to-asserter.

No further records found. In particular, I found no recorded assignment capturing the 2017 Minebea/Mitsumi share exchange for this patent. That is common — a parent/subsidiary share exchange often leaves the operating subsidiary as record owner and is not accompanied by a per-patent USPTO recording. This is itself a finding: absent a recorded transfer, Mitsumi Electric Co., Ltd. (now a MinebeaMitsumi Inc. subsidiary) remains the presumptive owner of record.

Timeline diagram

timeline
    title Ownership of US 8775582
    2010 : Japanese priority filed by Mitsumi
    2011 : US application filed
         : Inventors assign rights to Mitsumi
    2014 : Patent issued to Mitsumi
    2017 : Mitsumi becomes MinebeaMitsumi unit

NPE / troll-pattern signals

Verdict

Insufficient data — and, on the evidence available, the ownership chain shows no NPE signal whatsoever.

The only recorded event is the original inventors → Mitsumi Electric Co., Ltd. assignment recorded 2011-09-21 (reel/frame not confirmed from my search coverage), for which I could retrieve no correspondent of record. There is no post-issuance assignment, no shell LLC, no known asserter, no litigation, and no bankruptcy — so the patent remains with the original operating-company chain (Mitsumi Electric Co., Ltd., now a wholly-owned subsidiary of MinebeaMitsumi Inc. following the Jan 27, 2017 share exchange). Because the file contains only the original assignment and no downstream transfer, this falls squarely into the "Insufficient data / only the original assignment" category rather than any NPE category. Note the patent is already Expired – Fee Related (adjusted expiration 2031-11-08), so even an assertion scenario would have limited runway.

Verify directly at: USPTO Assignment Center — https://assignmentcenter.uspto.gov/ (search by patent number 8775582 or application 13/238,486); mirrored/indexed at https://assignment.uspto.gov/patent/index.html. Cross-check the legal-events tab at https://patents.google.com/patent/[US8775582B2](/patent/US8775582B2)/en, and confirm current owner/status in USPTO Patent Center.

Uncertainty flags for this section (do not treat as established):

1. Reel/frame numbers are not confirmed — I did not retrieve the Public Assignment Search record page for this patent; do not cite a reel/frame from this report.
2. Correspondent of record is not confirmed — the repeat-correspondent signal (the most valuable tell) could not be evaluated; a single-record chain also makes recurrence structurally impossible.
3. Record ownership vs. economic ownership after 2017 — the Minebea/Mitsumi share exchange is documented (MinebeaMitsumi corporate disclosures, Jan 27, 2017) but I found no recorded USPTO assignment reflecting it; Mitsumi Electric Co., Ltd. remains presumptively the owner of record.
4. "Shipped a product embodying the claims" is unconfirmed — the claimed subject matter is a factory provisioning tool; I found no evidence of commercial sale.

I'll research US 8,775,582's cited prior art references. Let me run several targeted searches.

Let me search for the front-page references and any USPTO/family records.

I found the front page. Let me retrieve the complete references list and confirm details.

Prior-Art Analysis — US 8,775,582 B2

Source and scope note

I attempted a direct USPTO lookup, but the search environment would not return a PatentCenter/Public-PAIR record page for 8,775,582. The citation list below is therefore grounded in the printed front page of US 8,775,582 B2 itself (the "(56) References Cited" field), as reproduced in the patent PDF (patentimages.storage.googleapis.com/.../US8775582.pdf) and cross-checked against Google Patents. That front page is the examiner/Applicant-cited reference list, so it is the correct universe for your request.

Two caveats up front:

1. The OCR of the front page is truncated in several spots (see the literal strings shown, e.g. "2005/027851," "2008/009848"). I reproduce them as printed and flag where the printed string is almost certainly a truncation rather than the true number.
2. These are references that were cited, not references that prevailed. US 8,775,582 issued over them, so none of them is known, from the face of the record, to have defeated any claim. The § 102 mapping below is a potential/hypothetical anticipation assessment, not a finding.

A third note (important and carried over from the earlier sections): nothing here reflects a litigation or CAFC docket. "Cited by" references (later patents citing 8,775,582) are not prior art and are excluded.

(A) US Patent Documents cited

Foreign patent documents cited

(B) Functional descriptions and § 102 potential, per reference

The descriptions below are deliberately conservative. Where I am not confident of a reference's actual disclosure, I say so and describe it only by the classification printed on the patent's face rather than inventing content.

The reference actually litigated in the patent's own text

WO 2003/101040 A1 (pub. 12/2003). This is the one prior-art document the specification expressly identifies and distinguishes. Per the patent's background section, it discloses a "secret key management device" with (i) an encryption unit that encrypts a secret key based on device identification information identifying a communication device, and (ii) a transmitting unit that sends the encrypted key to the communication device. The patent distinguishes it on the ground that the MAC address must be manually input to the secret-key manager, and the manager stores only the key, not the MAC/device list (col. 1, "Description of the Related Art").

• § 102 relevance: This is the closest art on the key-encryption aspect (part of claim 1(c)), and it is the strongest candidate for a § 102 challenge to the encryption sub-feature. It does not disclose the power-up-triggered auto-access, the pre-recorded list containing the device MAC address, the list-update/management step, or the folder-move-without-renaming step.
• Potential § 102 target: arguably only sub-elements feeding claim 1/claim 6's key-encryption limitation; it cannot anticipate any full independent claim as written. Would be used as § 103 art, not § 102 anticipation, against the full claim.

US patent references (provisioning / network-configuration cluster)

US 7,546,357 B2 (6/2009; Manchester et al.; class 709/220). 709/220 is the "network configuration / initial setup" art area. On its face this is the most on-point non-key reference for the provisioning concept (recognizing a device, configuring it over a network).

• Potential § 102 target: could be argued against the "device setting unit" + "setting management unit" concepts of claim 1 and method claim 6 if it discloses list-based assignment of a MAC address to a powering-up device. It would not reach the encrypted-key-folder-move limitation (claim 1(d)).

US 7,840,683 B2 (11/2010; Zhang; class 709/227). 709/227 is the client/server configuration-session art. Likely relevant to automatic device-side request/server-side response provisioning.

• Potential § 102 target: the "recognize an access from the communication device upon power up" element of claim 1/claim 6, at most.

US 7,856,646 B1 (12/2010; Groff et al.; class 725/42). 725/42 is interactive-TV / set-top-box art — relevant to the claimed STB/television species (claim 5) and to the content-provisioning environment.

US 8,161,527 B2 (4/2012; Curren; class 726/2). Class 726/2 is information-security / authorization. Likely relevant to the DRM/secret-key provisioning aspects.

• Potential § 102 target: the encrypted-key limitation (claim 1(c), claim 2/7 HDCP-Marlin subject matter).

US 2005/027851*A1 (12/2005; McKeown et al.; class 709/224). Network monitoring/management art.

US 2005/028926*A1 (12/2005; Illowsky et al.; class 710/104). Device configuration/setup art (710 = electrical computers, input/output).

US 2008/0046996 A1 (2/2008; Smith et al.; class 726/15) and US 2008/009848 A2 (4/2008; Smith et al.; class 726/3). Both Smith et al., both in information-security classes (726/15 = network security; 726/3 = key/credential management). These two are the most likely candidates among the published applications for disclosing key-encryption-and-distribution subject matter.

• Potential § 102 target: the key-encryption portion of claim 1/claim 6 and dependent claims 2/7. Note: the second is printed as "A2," which is anomalous for a US pre-grant publication (normally "A1"); treat the literal string with caution.

US 2010/0097527 A1 (4/2010; Shin) and US 2010/0257549 A1 (10/2010; Nam; 725/25) — TV/broadcast-device art. US 2010/0016683 A1 (1/2010; Lemmers et al.; 348/723) – video/display art. US 2008/0051027 A1 (2/2008; Lee; 455/3.06) and US 2008/0056722 A1 (2/2008; Hendrix et al.; 398/108) — broadcast/optical-distribution art. US 2008/0028318 A1 (1/2008; Shikuma; 715/744) — user-interface art.

US 2007/0211653 A1 (9/2007; Mizukoshi; 370/312) and US 2008/0115013 A1 (5/2008; Jung et al.; 370/400) — network/transport-layer art.

US 2009/0109980 A1 (4/2009; Zuili; 600/301) — medical-monitoring art; appears peripheral/unrelated, included perhaps for the "remote provisioning of a device" concept.

The late-dated US application publications (important timing issue)

Four cited publications carry publication dates after the 2010-10-01 priority date: US 2011/0237184 A1 (9/2011; Minoshima et al.), US 2011/0252440 A1 (10/2011; Sridhara et al.), US 2012/0227067 A1 (9/2012; Ma et al.), and US 2012/0265324 A1 (10/2012; Colombo et al.). Because this application was filed 2011-09-21, i.e. under the pre-AIA statute, a printed publication is § 102(a)/(b) prior art only if it predates the applicant's invention; a US patent or application publication can qualify under pre-AIA § 102(e) only if its effective US filing date is before the applicant's invention date. So:

• These four cannot be § 102(a)/(b) art on their face (published after the priority date), and their availability depends entirely on their filing/priority dates — which I have not verified here for Minoshima, Sridhara, Ma, or Colombo.
• US 2011/0252440 A1 (Sridhara et al.; 725/31 — content-protection/DRM class) is the most likely of the four to be substantively relevant (DRM key management), but its § 102 status is unconfirmed.
• Flag: if any of these four was filed after 2010-10-01 and had no earlier priority, it is not prior art at all and its citation was likely for § 102(e) formal reasons or examiner convenience. This needs a per-reference filing-date check to resolve.

Foreign references

• EP 1 276 275 A2 (1/2003; H04L 12/24). H04L 12/24 is network configuration/maintenance — likely relevant to automated network-device setup.
• JP 2008-028788 A (2/2008) and JP 2010-124254 A (6/2010) — I could not retrieve their content; no subject-matter characterization is offered. (Note: JP 2010-124254 was published 6/2010, i.e. before the 2010-10-01 priority, so it is facially available as art.)
• WO 03/101040 A1 — discussed above.

(C) Anticipation analysis (§ 102)

Claim 1 is the broadest independent claim and requires all of:

1. a device setting unit that recognizes a power-up access and writes list-sourced, MAC-containing setup info into the device;
2. a setting management unit that detects completion, changes the list, and manages the device accordingly;
3. a key information generating unit that pulls key info via the key file name in the list and encrypts it, the written setup info containing the encrypted key; and
4. after the write, the setting management unit moves the encrypted key from a "writing encryption key folder" to a "written encryption key storage folder" without changing the key file name.

Bottom line: No cited reference, on the material available here, discloses limitation (4) — the folder-to-folder move of the encrypted key without renaming — nor limitation (3)'s "key file name in the list → encrypt → include in setup info" chain. Anticipation under § 102 requires a single reference disclosing every element arranged as claimed (Net MoneyIN v. VeriSign). Because the "write-folder → written-folder, same filename" management feature appears to be a point of novelty that the examiner relied on for allowance, I would not assert anticipation of claims 1, 6, or 9 by any citation on the face of this patent. Claims 10 and 11 (system/method pairs with the device-side request/receive/execute/report steps) are likewise not anticipated by these references individually.

Where these references could plausibly be used:

• claim 2 / claim 7 (HDCP/Marlin key): Curren (US 8,161,527), Sridhara (2011/0252440), and the two Smith publications are the natural § 102 candidates for the type-of-key limitation only.
• claim 5 (STB/TV/PC/PDA/game machine species): Groff (US 7,856,646) and Nam (2010/0257549) are the natural art for the set-top-box/television species.
• claim 4 (apparatus stores the same address info the device uses to reach an HTTP server): the network-configuration references — Manchester (US 7,546,357), Zhang (US 7,840,683), and EP 1 276 275 — are the closest, though I cannot confirm any of them teaches the server-impersonation limitation.
• claims 3 / 8 (generating/outputting command information): the client/server provisioning references (Manchester, Zhang) are the closest. The specification itself notes the claimed commands are "normal data transfer commands used in a predetermined program, such as UNIX," which invites § 103 combinations.

Net assessment: the cited art is overwhelmingly directed to (i) generic network-device provisioning and (ii) DRM/secret-key distribution, with the combination and the folder-based key-file lifecycle management being what distinguishes the claim. The realistic prior-art posture for US 8,775,582 is § 103 obviousness-type, not § 102 anticipation.

(D) Uncertainty flags / what I could not verify

• I did not obtain a live USPTO PatentCenter record for 8,775,582; the reference list is taken from the patent's printed front page (which reproduces the USPTO data) and Google Patents. The list may be incomplete where the OCR truncated (e.g., between the "2010/0097527" and "2010/0257549" entries, and after "2012/0265324").
• Several identifiers are printed truncated ("2005/027851," "2005/028926," "2008/009848"). I have reproduced them literally and given the likely full forms only as annotations — per your instruction not to auto-correct identifiers.
• I did not verify the actual subject matter of most references; their functional descriptions are inferred largely from the classification codes printed on the patent's face. The exceptions where I have higher confidence are WO 03/101040 (described in the patent's own text) and the class-based grouping.
• § 102(e) timing for the four post-priority-date publications (Minoshima, Sridhara, Ma, Colombo) is unresolved and requires each reference's effective filing/priority date.
• No litigation or CAFC activity for this number was found (consistent with the earlier sections); "no litigation found" reflects search coverage only, not a certified clearance search.
• Claims 11 and 12 remain truncated in the supplied patent text, so their full limitations — and thus any § 102 mapping onto them — cannot be completed.

I'll research the prior art landscape for this patent, starting with the reference cited in the patent itself and related provisioning/DRM-keying art.

Let me pull details on the most relevant references — the Barnett auto-provisioning application and other key-provisioning art.

Let me look for the patent's own cited references and the key-injection/factory-provisioning art most on point.

Obviousness Analysis of US 8,775,582 B2 under 35 U.S.C. § 103

Note on the record supplied. The material I was given for this patent (Google Patents full text, fetched 2026‑09‑28) does not reproduce the front‑page "References Cited" list, the examiner's rejections, or the file wrapper. So I cannot tell you what art the examiner actually applied, or whether claim 1 was allowed over a §103 rejection. What follows is an independent, analyst‑constructed obviousness case using (a) the references the patent itself admits, and (b) prior art I located and dated against the 2010‑10‑01 priority date. I flag every place my confidence is limited.

A note on dates: the task header says "Current Date: April 26, 2026," while the source page timestamp is 2026‑09‑28. This inconsistency was already flagged in the earlier sections of this analysis and does not affect the §103 analysis, which turns on the 2010‑10‑01 priority date.

A note on identifiers: The litigations-summary section correctly warned against conflating this 8,775,582 with the Quanergy/Velodyne "'558" patent or the Penn/Lilly "'558" patent. I have not used any of those. All analysis below is tied to Mitsumi Electric's US 8,775,582 / application 13/238,486.

1. Legal framework and level of ordinary skill

Because application 13/238,486 was filed 2011‑09‑21 (before the AIA first‑inventor‑to‑file date of 2013‑03‑16), the pre‑AIA §§ 102/103 regime applies. Obviousness is judged under Graham v. John Deere, 383 U.S. 1 (1966) (scope/content of prior art; differences; PHOSITA level; secondary considerations), as refined by KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007).

A claimed combination is obvious where a PHOSITA would have had a reason to combine the references with a reasonable expectation of success. MPEP § 2143 lists the cognizable rationales; the ones most applicable here are:

• (A) Combining prior‑art elements according to known methods to yield predictable results;
• (C) Use of a known technique to improve similar devices in the same way;
• (D) Applying a known technique to a known device ready for improvement;
• (F) Design incentives / market forces producing predictable variations; and
• (G) Teaching, suggestion, or motivation in the prior art.

PHOSITA (proposed). A person with a bachelor's in EE/CS (or equivalent) and 2–4 years' experience in network device provisioning and/or factory‑floor manufacturing automation for consumer‑electronics devices (set‑top boxes, IPTV receivers, digital TVs), familiar with Ethernet/TCP‑IP, HTTP, NFS mounts, DRM keying (HDCP/Marlin), and standard file/folder management. The specification supports this level: it treats all the individual pieces (MAC addresses, encryption keys, Ethernet, HTTP servers, folder structures, UNIX commands) as conventional, and describes the invention as a coordination of them ("The command generated by the device setting unit 35 is a normal data transfer command used in a predetermined program, such as UNIX").

2. Scope and content of the prior art

All references below predate 2010‑10‑01 by filing/priority/publication as noted.

References I excluded as post‑dating the priority date (not available as §102 art): US 2012/0137137 & US 2014/0089659 (Brickell — priority 2010‑11‑30, after 2010‑10‑01); the Data I/O automated‑manufacturing family (US 2016/0188910, WO 2016/109580 — priority 2014‑12‑30); US 2016/0188910; and the various CN 102xxx/103xxx/105xxx/106xxx filings (2011–2017). These can support a general-knowledge narrative but cannot be relied on as §102/§103 art here.

What the '582 actually added over this art. Reading claim 1 against RA1–RA7, the genuinely distinguishing limitations appear to be:

1. The device setting unit pulls pre‑recorded, device‑specific setup info (including the MAC) out of a list and writes it into the device on the device's power‑up access (RA2 is device‑side auto‑provisioning but the STB supplies its own MAC; the factory‑write of the MAC is the delta — covered by RA6/RA7 and the admitted background).
2. The setting management unit detects the end of the setting process and then changes the list to reflect what was written (RA3 has a mapping table; RA4/RA5 have logs; but "rewrite the provisioning list from the completed write" is a coordination step).
3. **The key info is fetched by its key file name from the list, encrypted, and — after the write — the encrypted key is moved from a "writing encryption key folder" to a "written encryption key storage folder" without changing the key file name.
4. (claim 4 only) The apparatus stores address info identical to the HTTP‑server address pre‑registered in the device, so the device dials the factory tool instead of the server.

Limitations (3) and (4) are where any nonobviousness argument must live.

3. Claim‑by‑claim obviousness analysis

Claim 1 (apparatus — independent)

Ground 1A — Barnett (RA2) in view of WO 2003/101040 (RA1), further in view of RA6/RA7 (factory MAC/serial writing) and RA3 (management list).

• "device setting unit to recognize an access from the communication device upon power up … acquire setup information … from list information pre‑recorded in the communication device setting apparatus, and perform a setting process to set the acquired setup information in the communication device" — RA2 discloses the power‑up trigger and the server‑side provisioning exchange, and its Background expressly frames the problem as eliminating manual entry of MAC/GUID. RA6/RA7 and the '582's own admitted background supply the factory‑write of the MAC/serial into the device. Combining an auto‑dialing power‑up handshake (RA2) with a factory key/identifier write table (RA6/RA7) is the predictable union of two known provisioning techniques.
• "setting management unit to detect an end of the setting process … change the list information … and manage the communication device according to the changed list information" — RA2 discloses maintaining and updating "a list of authorized set top boxes" as devices are provisioned; RA3 discloses a MAC mapping table that is written upon provisioning and monitored; RA4 discloses receiving a log report indicative of addition of the key to the device. Rewriting the master list from the just‑completed write is the routine database‑consistency step a PHOSITA would apply.
• "key information generating unit to acquire key information via a corresponding key file name contained in the list information, and encrypt the acquired key information … setup information contains the encrypted key information" — RA1 (WO 2003/101040) discloses exactly the encrypt‑the‑key‑before‑sending operation, based on device identification, and is admitted prior art in the '582. RA4/RA5 disclose key material referenced/loaded via key files during factory provisioning. Indexing the key by a file name stored in the management list is an ordinary data‑modeling choice.
• "after the … setting process … moves the encrypted key information from a writing encryption key folder to a written encryption key storage folder without changing the key file name" — this is the inbox → archive file‑management idiom. RA4 (log report of completed key addition) and RA5 (key‑injection audit/logging) both contemplate tracking which keys have been written, which is precisely the information the folder move encodes. See the dedicated discussion in §4 below.

Ground 1B — WO 2003/101040 (RA1) as the primary reference, in view of Barnett (RA2) and RA3.

Run in reverse: take the admitted secret‑key‑management device (RA1) and add the automated power‑up auto‑provisioning and list management of RA2/RA3. The '582's own Background says RA1's shortcoming was that "the MAC address … must be manually input," so the patentee frames the invention as the automation of RA1 — and RA2/RA3 supply exactly that automation. Under KSR, "if a technique has been used to improve one device, and a person of ordinary skill … would recognize that it would improve similar devices in the same way, using the technique is obvious."

Claim 2 / Claim 7 — HDCP and/or Marlin key

Obvious. HDCP and Marlin are named in the '582 only as examples of DRM key types. RA2 expressly recites downloading a "DRM encryption key"; RA4/RA5 concern cryptographic/content keys. Selecting HDCP or Marlin as the key type is a design choice among known DRM schemes for set‑top/HDMI devices (MPEP 2144.04 — "obvious to try" a finite set of identified, predictable options). No unexpected result is attributed to the choice.

Claim 3 / Claim 8 — device setting unit generates command information and outputs it to the device

Obvious. RA2 has the middleware server sending a provisioning message/software to the STB; RA4's servers "authorize" the addition of key material to the device (i.e., issue instructions). Generating a command/file‑transfer instruction to cause the client to fetch data is the ordinary client‑server mechanism; the '582 itself characterizes the command as "a normal data transfer command used in a predetermined program, such as UNIX." Implementation detail, not patentable weight.

Claim 4 — apparatus stores address information identical to the HTTP‑server address pre‑registered in the device

Obvious, but the weakest of the dependent claims if argued. Two independent supports:

1. The '582's own specification states the feature is a substitution: the device "can access the communication device setting apparatus 21 … as if the STB 12 had accessed the HTTP server 11." Giving a factory tool the same network address the device already auto‑dials is the natural, predictable way to intercept an existing power‑up auto‑dial without modifying the device ("the STB 12 is not required for a special control process"). Where the specification itself frames the step as a substitution of one known element for another to obtain a predictable result, MPEP § 2143 rationale (B) applies.
2. RA2 already involves the device autonomously contacting a fixed server on power‑up; re‑pointing the device's pre‑registered server address to the provisioning server (or provisioning the server at that address) is a routine network‑configuration expedient.

Caveat: I did not find a pre‑2010‑10‑01 reference that explicitly discloses "same IP address as the HTTP server." This limitation is therefore the most exposed to a nonobviousness argument if the patentee can show the enforcement mechanism (device firmware hard‑codes the server address and refuses to be reconfigured) was unconventional. That argument is not supported by the '582 text, which presents the address match as a simple setup step.

Claim 6 (method — independent)

Tracks claim 1 step‑for‑step. Same grounds (1A/1B). The method steps are performed by the same conventional units; In re Kollar / In re Durden‑type "process/apparatus" symmetry means the method claim rises and falls with claim 1. RA2 discloses the ordered steps of power‑up → request → server provisioning → key download; RA1 supplies the encrypt‑then‑transmit step; RA4 supplies the write‑completed log/report step that maps to "detecting an end of the setting process" and "changing the list."

Claim 9 (non‑transitory CRM)

Obvious. A Beauregard‑style medium claim storing a program for the claim‑6 method adds no separate inventive subject matter; a non‑transitory computer‑readable medium storing provisioning software is conventional (and the '582 itself describes supplying the program on "a USB memory, a CD‑ROM, a DVD, a removable recording‑medium 48").

Claim 10 (communication system — apparatus + provisioned device)

Adds the device‑side control unit performing: request setup info on power‑up; receive command information; execute it to fetch setup info from the apparatus's storage; output an end‑of‑recording message.

Obvious over RA2 alone (device side) plus RA1/RA4 (server side). RA2 discloses the STB, on power‑up, requesting provisioning and receiving server‑supplied provisioning data (software + DRM key), and its flow implicitly requires the server to know the provisioning completed. RA4 discloses the server receiving a report that the key material was added to the device — i.e., the "end‑of‑recording message" element. The combination of a client that fetches provisioning data by executing server‑supplied commands with a server that logs completion is squarely a predictable client‑server architecture; the '582 expressly says the STB behaves "as if it had performed a predetermined command in response to a command execution request from the HTTP server."

Claim 11 (method — device‑side steps)

Independent in form; adds the same device‑side steps as claim 10 in method form. Same analysis as claim 10.

⚠️ Flagged inconsistency/limitation carried over from the earlier section: claims 11 and 12 are truncated in the supplied text ("executing, by the control unit of th…"), and claim 12 was not included. My claim 11 analysis is therefore partial, and claim 12 is unanalyzed. If claim 12 recites a further limitation (e.g., a specific end‑of‑recording signal or folder move), the conclusions for it must be revisited against the untruncated text.

4. The one limitation most likely to be argued both ways: the "no‑rename folder move"

The final wherein clause of claim 1 / claim 6 — moving the encrypted key from a writing encryption key folder to a written encryption key storage folder without changing the key file name — is the most likely point of novelty (it reads as an amendment added to secure allowance).

Case for obviousness:

• Moving a completed work item from a "to‑do / in‑progress" folder to a "done/archive" folder while preserving its filename is a pervasive software idiom (mail inbox→archive, print queue→spool, build src→dist). Applying that idiom to a key‑writing workflow is MPEP 2143 rationale (C)/(D): a known technique applied to a known device ready for improvement, yielding a predictable result.
• The purpose is a generic bookkeeping benefit the specification itself states flatly: "the file name does not become complicated and the management can be performed easily." A result that is predictable and merely a matter of design choice ("do not complicate the file name") does not rebut obviousness. Compare KSR: "the improvement is [no] more than the predictable use of prior art elements according to their established functions."
• RA4 (log report of completed key addition) and RA5 (key‑injection audit/logging) both recognize the need to record which keys were actually written, which is the exact information the folder move carries.

Best counter‑argument the patentee could make:

• That preserving the original filename across folders creates a verifiable 1:1 link between the management‑list "HDCP/Marlin key file name" entry (FIGS. 7A/7B) and the archived encrypted key, and that RA4/RA5 use log records rather than a folder‑rename‑free file move — arguably a different mechanism. This is a real distinction, but it is an argument about form, not result, and would need an unexpected‑results or teaching‑away showing to prevail. I did not find teaching away.

My assessment: the no‑rename folder move is at the margin — likely obvious to a PHOSITA, but it is the limitation an examiner most plausibly relied on to allow. Without the file wrapper I cannot confirm this.

5. Motivation to combine (applying MPEP § 2143)

1. Common field and common problem. RA1, RA2, RA3, RA4, RA5 all sit in secure/automated provisioning of network‑connected electronic devices; all address the same defect the '582 names (manual handling of device identifiers and keys causes input errors, illegal copying, and management burden). RA2's Background independently indicts "manually inputting … IP addresses, media access control (MAC) addresses, and globally unique identifiers" as error‑prone.
2. Rationale (A): combining RA2's power‑up auto‑provisioning + list management with RA1's encrypt‑the‑key mechanism yields nothing more than the sum of the two known functions — predictable.
3. Rationale (C)/(D): the factory‑floor MAC/serial‑write technique (RA6/RA7) is a known technique applied to a known device (a network provisioning tool) ready for improvement by automation.
4. Rationale (F) — market forces: automating factory provisioning directly reduces labor cost, cycle time, and rework — a strong, articulated design incentive in both the '582 and RA2.
5. Rationale (G) — explicit suggestion: RA4 teaches receiving a completion report after key addition; this is a concrete teaching that motivates the "detect an end of the setting process" and "change the list" steps of claim 1.

6. Rebuttal considerations and secondary considerations

• No unexpected results are documented in the '582; the stated advantages (fewer errors, less time, better security, no operator handling of confidential data) are precisely the expected consequences of automating a manual provisioning step — the same advantages RA2 claims for its background problem.
• No teaching away identified: RA1/RA2/RA4 are mutually compatible, and no reference disparages combining encryption with auto‑provisioning or with a management list.
• No evidence of commercial success / industry praise / copying / long‑felt need nexus is present in the record I have. The patent is Expired – Fee Related (per the earlier bibliographic section), which undermines any commercial‑success narrative.
• "Hardware processor configured to execute" language in claim 1 imposes only a generic‑computer implementation; the specification says the method "may be easily performed on a general‑purpose personal computer by installing the program," so this adds no weight.

7. Grounds summary

8. Uncertainties, limitations, and recommended verification

1. I do not have the file wrapper or the examiner‑cited art. I could not retrieve US 8,775,582's front‑page "References Cited" or any §103 rejection/allowance record; my searches did not surface the prosecution history. All grounds above are my own construction, not the examiner's. Verification: run US 8,775,582 in USPTO Patent Center → "Documents & Transactions" for the Notice of Allowance and any §103 rejections, and pull the examiner's cited art.
2. RA5 (US 2011/0010770) date unconfirmed. I could not verify its exact filing date in the available results; confirm before relying on it as statutory art.
3. RA6/RA7 are Chinese‑language references and I relied on machine‑translated abstracts; a human translator should confirm they disclose writing a MAC address (not merely a serial number) to an STB on a production line before they are used to supply the "write the MAC into the device" element.
4. Claim 11 is truncated and claim 12 is absent from the provided text. My analysis of those claims is incomplete; the untruncated claims must be checked for any additional limitation.
5. Claim 4 is the limitation I am least able to map to a specific pre‑2010‑10‑01 reference ("same address as the HTTP server"). It remains obvious on the MPEP 2143(B) substitution theory and on the '582's own "as if" framing, but I found no explicit prior‑art teaching of that exact feature and I say so plainly rather than overstate.
6. No litigation history for this patent (per the earlier section) means there is no court's or PTAB's validity determination for this patent to cite; there is no IPR/§103 record to leverage either way.

Bottom line: Claims 1, 2, 3, 5, 6, 7, 8, 9, 10, and 11 are, in my assessment, likely obvious over WO 2003/101040 + Barnett (US 2010/0287582) + US 7,826,453 + a factory MAC/serial‑writing reference, with the strongest motivation being the references' shared, explicitly articulated goal of eliminating manual, error‑prone handling of MAC addresses and DRM keys. The single limitation most resistant to summary obviousness is the no‑rename folder‑to‑folder move of the encrypted key (claims 1 and 6); it is probably obvious as a known bookkeeping idiom (US 9,692,737 / US 2011/0010770 supply the write‑completion/logging teaching), but it is the limitation I would want the file wrapper to confirm was the actual point of allowance. This is analysis, not legal advice, and any conclusion should be confirmed against the primary prosecution record.