US 8934610

I'll verify the patent details and check for any 2026 litigation activity before summarizing.

US Patent 8,934,610 B2 — Summary

Verification note: I searched for litigation and CAFC docket activity tied to this specific number and found no 2026 (or other) CAFC appeal, PTAB proceeding, or district-court case matching US 8,934,610. A search for "8934610" surfaced only an unrelated Spanish administrative record (expediente 17/8934610-9), which does not concern this patent. Any statement that this patent is in 2026 litigation would be unfounded. Details below come from the authoritative patent text (Google Patents) unless otherwise flagged.

Bibliographic data

Caveat on assignment: I have no authoritative post-issue reassignment record in hand; the only clearly documented assignment is the original 2013-12-11 transfer to Hitachi Information & Telecommunication Engineering, Ltd. If a 2026 ownership change exists, I did not find it.

Abstract (as issued)

A system transmits a record file of voice or image data created by a local device to a center device over a network and manages it there. The center device receives attribute information about the record file — including the record file ID — from the local device, further acquires extended attribute information associated with that attribute information from a PBX, call control server, or customer server, and stores a management table containing both. The extended attribute information "suggests frequency of the reference for the record file in the local device," and the center device decides the timing of the upload request for the record file based on that extended attribute information.

Plain-language overview of each independent claim

Claim 1 — System (two-device architecture). A first device makes a record file of voice or image data; makes "first attribute information" describing it; stores the record file in a first storage tied to an identifier; and sends the first attribute information (with the ID) across the network. The second device (a) receives that first attribute information, (b) additionally obtains "second attribute information" associated with the first attribute information from a third device that is different from the first device, (c) stores management information containing both sets of attribute information, (d) later receives the record file itself and stores it, and (e) updates the management information matching the received file's identifier.

Key concept: attribute metadata goes to the center first; the heavy media file follows later; a separately-networked third source enriches the metadata.

Claim 7 — Method. The same steps as claim 1, recited as a file management method (first device creates/stores/transmits attribute info; second device acquires first attribute info, acquires second attribute info from a third device, stores combined management information, later receives and stores the record file, and updates the management information per the identifier).

Claim 8 (dependent on 7) narrows the method to a telephone context: the first device is connected to a telephone system on the public telephone network, and the second device obtains the second attribute information from a PBX, a call control server in that telephone system, or a customer server.

Claim 9 — Center-side system (second device alone). A system comprising just the second device, which receives first attribute information (including the record file's identifier) from the first device over the network; acquires second attribute information associated with the first attribute information from a third device; stores management information containing both; after acquiring the first attribute information, receives the record file, stores it, and updates the management information per the identifier. This is the center-side counterpart to claim 1.

Claim 10 — Center-side method. The method counterpart of claim 9, with the same center-only steps.

Claim 11 — Non-transitory computer-readable medium. A storage medium holding a two-part program: a first program that, on a first server, creates the record file, creates the first attribute information, stores the file associated with that attribute information, and transmits the attribute information (with the file ID) to a second server over a network; and a second program that, on the second server, acquires the first attribute information, acquires second attribute information from a third server, stores combined management information, receives and stores the record file, and updates the management information per the identifier. This is the software-claim version of claim 1, with servers substituted for devices.

Dependent claims 2–6 (for context)

• Claim 2: Structural recitation of claim 1's devices — local device has a record file creation unit, attribute file creation unit, first storage unit, and transfer control unit; center device has first and second attribute processing units, a management unit, and a second storage unit that updates the record file's storage-location information on receipt.
• Claim 3: Attributes are transmitted for a file already stored locally, then the record file is transmitted; the center flips the management information to "reception finished."
• Claim 4: First device connected to a telephone system; second attribute information obtained from a PBX or call control server as the third device.
• Claim 5: Same telephone context but second attribute information obtained from a customer server as the third device.
• Claim 6: The second storage unit keeps a management table with at least a record file identifier, an address specifying the first storage unit, and a reception flag indicating whether the second device has received the record file.

Notable scope observations

• The transfer-timing / reference-frequency logic featured in the abstract and specification (e.g., the third embodiment's transfer control condition table and the "local cash" concept, where frequently referenced record files are retained in the local storage after upload and served locally to terminal 27) is described prominently but is not expressly recited in the independent claims as issued. The independent claims are framed around the attribute-first/file-later sequence and the third-party enrichment of attribute data.
• The specification is written to cover alternatives — batch/periodic transmission of attribute files, a local-side transfer control condition table (124′), performing "phase 3" (file upload) before "phase 2" (extended attribute acquisition), and a fifth embodiment applying the same architecture to image files in an entrance/exit-management system (with ETC/highway-gate variant).
• Related similar documents listed in the family record include US 9,471,592 B2 and US 9,400,804 B2 (same title), which I did not independently verify here.

Uncertainty disclosure: I could not access USPTO PatentCenter/Public PAIR or the CAFC docket directly to confirm current ownership, fee status beyond the 8th-year payment, or the absence of any unreported 2026 proceeding. My "no litigation found" statement reflects the absence of search hits, not a certified docket clearance.

I'll research litigation involving US patent 8934610. Let me search multiple sources.

The first results don't show litigation. Let me search litigation-specific databases.

No litigation found yet. Let me search more targeted litigation sources.

Summary of Findings

Based on my searches of patent litigation resources (Unified Patents Portal, Docket Alarm, Justia, CourtListener/Google Patents pages, and general web searches for the specific number 8,934,610 / US8934610B2), I found no litigation involving U.S. Patent No. 8,934,610.

What I checked and what came back

Patent identity confirmation (to rule out similar-number confusion)

• Patent: US 8,934,610 B2 — "File management system, method and computer program"
• Inventors: Toshiaki Koyama; Toyoki Yamagishi
• Assignee: Hitachi Information & Telecommunication Engineering, Ltd.
• Application: US 14/102,804; filed 2013-12-11; granted 2015-01-13
• Priority: 2012-12-12 (JP 2012-271415, which issued as JP 6013895 B2)
• Family members: EP 2744185 A1 (noted "Withdrawn"); JP 6013895 B2

False positives I encountered and excluded

• A Spanish BOE administrative listing containing "17/8934610-9" — this is a Spanish Social Security "expediente" number, not the patent.
• Nuance Communications Inc. v. Tellme Networks Inc. (D. Del., 707 F. Supp. 2d 472) — this case did discuss a "Hitachi patent," but it concerned a voice-recognition/PBX patent and the '088 patent at issue; it is not U.S. 8,934,610. I did not count it.
• Various PTAB filings referencing unrelated patents (e.g., the '341, '794, '508 patents) — none involve 8,934,610.

Answer to your request

No litigation is known to me — no district court (PACER/CAFC) case, no ITC action, and no PTAB post-grant proceeding (IPR/PGR/CBM) asserting or challenging U.S. Patent No. 8,934,610 was identified. Because there is no case, I cannot provide plaintiff, defendant, jurisdiction, case number, filing date, or outcome.

Important caveats

• This is a negative finding based on the sources reachable in my search, not a guarantee. Litigation records can be sealed, recently filed, or indexed only behind paywalls (e.g., full PACER dockets, Docket Navigator, Lex Machina) that I could not fully query.
• The patent is owned by a non-practicing-style operating company subsidiary of a large manufacturer (Hitachi), which is generally less likely to be a serial litigant, consistent with a finding of no asserted litigation. Its one EP family member is noted as withdrawn, and the closest related documents citing it are later patent filings, not lawsuits.
• If you need a definitive check, I'd recommend confirming directly at:
  • Unified Patents litigation portal: https://portal.unifiedpatents.com/litigation/caselist
  • PACER / CourtListener RECAP docket search for "8,934,610" or "8934610"
  • The USPTO PTAB (PATENT TRIAL AND APPEAL BOARD) caselist for any post-grant challenge

If you can grant more search steps, I can attempt to query those specific databases directly to double-confirm.

I'll verify the "no proceedings on file" default with targeted searches before writing the analysis.

Proceedings overview

Zero AIA trial proceedings on file. The canonical USPTO Open Data Portal (ODP) structured block returns no IPR, PGR, or CBM proceeding for US 8,934,610, and my independent web searches surfaced no petition, institution decision, Final Written Decision, or PTAB appeal naming this patent. The count is therefore 0 total — 0 active, 0 claims invalidated, 0 claims sustained, 0 settled, 0 institution denied. The defensive posture this gives a defendant is the honest, unglamorous one: the claims are untested at the Board, so you have no ready-made invalidity roadmap and no estoppel shield — but you also have a clean slate and no § 325(d)/§ 315(e) baggage from someone else's failed petition.

Per-proceeding detail

None to report. There is no proceeding number to populate, and I will not invent one. I ran the following checks, all negative:

Important negative-context items (not proceedings, but adjacent records that could be misread as such):

• EP 2744185 A1 — the European counterpart — is "not_active / Withdrawn." That is an EPO prosecution outcome (the application was withdrawn after filing; the EPO's extended European Search Report mailed 2014-04-28 is the sole non-patent citation in the US file). It is not an opposition and not an AIA trial. Do not let anyone characterize it as an invalidation.
• JP 6013895 B2, the Japanese counterpart, is listed as active — a JP invalidation trial or opposition is a separate, non-US question I did not search. Flag if you have a Japan exposure.
• Sibling US patents with the identical title appear in the "Similar Documents" list: US 9,471,592 B2 and US 9,400,804 B2. These are likely family members/continuations. I did not verify whether those numbers have been challenged — if the patent owner is asserting the family, a petition against a sibling may exist and would be relevant context even though it does not estop anything against the '610 claims. This is the single biggest gap in my check, and it is the one thing I'd pay a docket service to confirm.

Strategic summary

Claim status: everything is UNTESTED. Nothing has been canceled, and nothing has been confirmed. Independent claims 1, 7, 9, 10, and 11 and dependent claims 2–6 all stand as issued on 2015-01-13. There is no narrowed claim set and no FWD to point to. Anyone who tells you "the claims were upheld" is wrong — silence from the Board is not a merits win, it just means no one with standing and budget has pulled the trigger.

Estoppel landscape: empty, and that cuts your way. Because there is no prior petitioner, there is no § 315(e)(2) estoppel constraining you, and no § 325(d) "same art, same arguments" discretion problem inherited from an earlier challenge. You are free to build the best ground against the strongest independent claim rather than being forced to differentiate from a predecessor's failed theory. Conversely, the patent owner has no adverse PTAB record to exploit either — you get no free claim-construction ruling and no Board finding that the specification fails to support a limitation.

Pattern signals: none. No serial petitioner, no Unified Patents-type defensive aggregator in the chain, no patent-owner appeal history. The ownership profile — a single large Japanese corporate assignee (Hitachi Information & Telecommunication Engineering, Ltd.), maintenance fees paid at the 4th (2018) and 8th (2022) years, anticipated expiration 2033-12-11 — is the profile of a portfolio/operational patent, not an assertion vehicle. That is the strongest analytical signal here: a patent asserted in anger (especially against multiple defendants or in an NPE-style campaign) almost always attracts an IPR within a year of service. The absence of any petition suggests this patent has not been asserted in a US district court at scale in the ~11 years since issuance. I could not access PACER to confirm a litigation docket search, so treat that as inference, not certification.

One substantive caveat worth knowing before you decide whether to file. The features that get the most airtime in the specification — the transfer control condition table, the "local cash" retention of frequently-referenced files (spec ¶ describing terminal 27 reading directly from local storage 22), and the reference-frequency-based upload timing — are not recited in the independent claims as issued. The independent claims are pitched at a much broader idea: send the lightweight attribute metadata (including the ID) to the center first, let the center enrich it with second attribute information from a third-party device, and upload the media later. That breadth is good for the owner against you and is exactly the kind of claim set where a clean § 103 combination of the cited references is the right attack — and where a § 112 written-description attack on the enrichment limitation is worth scoping.

Recommended next steps

If you are a defendant and the owner has asserted 8,934,610 against you:

1. Don't wait for an invalidity roadmap that doesn't exist. File your own petition. Your § 315(b) clock runs one year from service of the complaint (or from service of a complaint on a privy/RPI) — diary it immediately.
2. Start from the art already in the file, because it's thin and identified. The examiner had essentially one primary reference, JP 2010-219734 A (Hardis System Design), cited on the face of the patent and relied on as the "YD" reference in the EPO search report, plus US 6,252,947 B1 (Diamond) as "Y." Also of record: US 7,203,288 B1 (Dictaphone) and US 2006/0242208 A1 (Microsoft). The examiner allowed these claims with no substantive rejection, which means a new combination of references — particularly art that teaches the third-party enrichment step (center device pulling attribute data from a PBX/call-control server/customer server and resolving it to the record by time and IP/telephone-number matching) — is where the § 103 case lives. That matching/consistency-resolution limitation is the most vulnerable element because it is the least well-supported by the cited art.
3. Scope a § 112 parallel attack. Independent claim 1 requires acquiring "second attribute information associated with the first attribute information" from a third device but never defines the association mechanism in claim terms; the spec supplies it only through the time-and-IP-address consistency decision. Consider whether the claim is enabled/written-described across its full scope. An IPR cannot reach §§ 112 (it's § 102/§ 103 only), so this is a district-court or ITC theory or, if the patent is eligible, a PGR — but PGR is available only within 9 months of a claim issuing, and these claims issued in 2015, so PGR and CBM are time-barred. Your AIA avenue is IPR or nothing.
4. Do your own docket check on the siblings. Confirm whether US 9,471,592 B2 and US 9,400,804 B2 (same title) have been petitioned. A prior Board construction of the shared specification's "attribute information" / "management information" terms could be highly useful collateral, and a prior petitioner's estate could be a joinder or estoppel consideration.

If you are evaluating a demand letter that cites US 8,934,610: the patent is intact and un-narrowed, so treat the demand as serious and do not assume invalidity. But note the practical reality — an 11-year-old, unasserted, un-petitioned software/telephony patent from a large operating company is a negotiation posture far more often than a litigation one. That framing should shape your response strategy and your tolerance for filing a PTAB petition as leverage.

Milestone calendar: not applicable — with no pending proceeding, there is no institution deadline, no oral hearing, and no statutory 1-year FWD due date to track. If you file, the deadlines you create are: (a) your § 315(b) one-year bar date from service; (b) a § 315(a) bar if you filed a DJ action first; and (c) the Board's three-month § 314(b) institution deadline and the twelve-month § 316(a)(11) FWD deadline from institution.

Citation/verification note: I cite no FWD, no judge panel, and no appeal docket because none exists. Where you would ordinarily see links to USPTO PTAB E2E or CourtListener, the correct entry is "no record found." The authoritative negative is the USPTO ODP structured block supplied with this task; my web checks (queries listed above) corroborate it, but I could not reach PATENT CENTER, PTAB E2E, or PACER directly, so this is a well-supported negative rather than a certified docket clearance.

I'll research the assignment record for this patent before reconstructing the chain.

Analyst note on sourcing: I could not open a rendered Assignment Center record page in this session (the assignment databases returned no indexed hits via web search, and a direct record view was not retrievable). What follows is anchored to the USPTO-derived legal-events data on the patent's Google Patents page (fetched 2026-09-28), which mirrors the Assignment Center's Abstract of Title, plus Hitachi corporate filings. Every reel/frame, date, and name below is sourced; anything I could not retrieve is explicitly flagged as a data gap rather than filled in.

Inventors

The assignment was executed by the inventors directly in favor of their employer-of-record, five to eight days before the US application was filed (2013-12-11). That is the ordinary employee-invention assignment pattern.

Unusual patterns: none detected. There is no evidence of either inventor departing the assignee, no co-ownership fragmentation, and no inventor-held residual rights. Both inventors appear on a single corporate chain. I have no data source for their later employment, so I cannot affirmatively clear a "both departed within 12 months" scenario — but there is no recorded assignment activity consistent with a post-departure portfolio sale, which is the pattern that would matter here.

One entity-name nuance worth flagging (not an inventor issue, but it touches the chain): the assignee recorded on 2013-12-11 is "Hitachi Information & Telecommunication Engineering, Ltd." — an entity created only on 2013-04-01 by the merger of Hitachi Information & Communication Engineering, Ltd. and Hitachi Computer Peripherals Co., Ltd. (Hitachi press release, 2013-03-08). The JP priority application (JP 2012-271415, filed 2012-12-12) therefore predates that merger by ~4 months. I did not verify the JP applicant of record for JP 2012-271415; if it names the pre-merger entity, the US filing entity is a successor by merger, which is exactly why no separate "merger" assignment appears in the US record (see below).

Original assignee

Hitachi Information & Telecommunication Engineering, Ltd. (Japanese: 株式会社日立情報通信エンジニアリング) — Nishi-ku, Yokohama (Minato Mirai), Kanagawa, Japan. Also styled in the record as "HITACHI INFORMATION & TELECOMMUNICATION ENGINEERING, LTD."

• Primary line of business: design, development, manufacture, sale and repair of ICT infrastructure — servers, storage, communications networking equipment — and software/ICT systems engineering. It is a 100%-owned consolidated subsidiary of Hitachi, Ltd. (TSE: 6501) (Hitachi FY2014 and FY2017 annual reports list it at 100.0% voting rights).
• Current status: OPERATING. The company still maintains a live corporate profile at hitachi-ite.co.jp showing FY2025 revenue of ¥77.6 billion and 2,906 employees (as of 2026-03-31). No dissolution, bankruptcy, or liquidation. No Chapter 7/11 (it is a Japanese entity; no US insolvency proceeding).
• Did they ship a product embodying the claims? Strong circumstantial support; not directly evidenced. This patent claims attribute-first/file-later management of call-recording files generated off an IP-PBX and enriched from a PBX, call control server, or customer server. Hitachi transferred its IP telephony / PBX design, development and manufacturing business into this exact entity by end of March 2014 — i.e., within ~3 months of this patent's filing (Hitachi press release, 2013-12-02). The patent's architecture maps onto that product line. However, I found no product literature, datasheet, or patent-marking evidence tying a specific commercial product to independent claim 1, so I record this as a plausible-but-unproven product nexus, not a finding.

Assignment timeline

The Assignment Center record for US 8,934,610 contains exactly one recorded assignment — the original, pre-issuance, inventor-to-employer assignment. There are no post-issuance assignments recorded. Per the USPTO-derived legal events, the chain is a single link:

• 2013-12-03 to 2013-12-05 (executed) / recorded 2013-12-11 — Reel 031758 / Frame 0263
  • Conveyance: Assignment (CONVEYANCE TEXT: "ASSIGNMENT OF ASSIGNORS INTEREST")
  • Assignor: KOYAMA, TOSHIAKI; YAMAGISHI, TOYOKI (signing dates 2013-12-03 to 2013-12-05)
  • Assignee: HITACHI INFORMATION & TELECOMMUNICATION ENGINEERING, LTD.
  • Correspondent of record: NOT RETRIEVABLE from the sources available to me. The legal-events abstract exposes the reel/frame and the parties but not the recording correspondent. This is a genuine data gap, not a null result — see the note under Signal 3.
  • Context: Original employee-invention assignment, recorded on the same day the US application was filed. Not a sale, not a fire-sale, not a reorg. The assignee is an operating Hitachi group company that had itself been formed by merger eight months earlier.

Subsequent USPTO legal events (non-assignment, included for completeness):

Fee-status observation (flagged, not asserted): the next maintenance fee — the 11.5-year/12th-year fee — fell due 2026-07-13 (11.5 years after the 2015-01-13 grant), with a six-month surcharge grace period to 2027-01-13. The 2026-09-28 legal-events snapshot shows no 12th-year payment event. This is unremarkable on its face (the owner has a habitual pattern of paying ~2 weeks early, so a payment event should appear around mid-2026) and most likely reflects feed lag rather than lapse — but it is worth a Patent Center / fee-history check, because an unpaid or disputed 12th-year fee is the one thing that would change the ownership analysis of an otherwise static chain. Do not treat this as a lapse finding on this evidence.

JP family member: JP 6013895 B2 (issued 2016-10-25) is the counterpart of the same priority filing.
EP family member: EP 2744185 A1 — status not_active / Withdrawn. No EP assignment chain is therefore commercially relevant.

Timeline diagram

timeline
    title Ownership of US 8934610
    2012 : JP priority application filed
    2013 : US application filed
         : Assigned to Hitachi ITE Ltd
         : Reel 031758 Frame 0263 recorded
    2015 : Patent issued
    2018 : 4th year maintenance fee paid
    2022 : 8th year maintenance fee paid
    2026 : 12th year fee window closes

NPE / troll-pattern signals

Verdict

Insufficient data — and specifically, only the original assignment of record, with no NPE activity of any kind.

Justification: the sole recorded assignment is reel 031758/0263, executed 2013-12-03 to 2013-12-05 and recorded 2013-12-11, conveying the application from inventors Koyama and Yamagishi to Hitachi Information & Telecommunication Engineering, Ltd. — a 100%-owned, still-operating Hitachi subsidiary that has paid both the 4th-year (2018-06-28) and 8th-year (2022-06-29) maintenance fees as a large entity. Because the entire chain consists of that one pre-issuance, inventor-to-employer assignment, there is no shell entity, no asserter, no cascade, no bankruptcy, and no aggregator to evaluate — the factual predicate for any NPE verdict is absent, which is the definition of "insufficient data" here. My prior litigation research found no suit, so the operating-company-assertion bucket is likewise inapplicable. Bottom line for a monitoring watchlist: this is a clean, single-link Hitachi chain with no recorded external transfer in 13 years — a low-priority monitoring target unless (a) the 12th-year maintenance fee proves unpaid, or (b) a Hitachi group IP divestiture package surfaces it. The one actionable data gap is the correspondent of record on reel 031758/0263, which is recoverable from Assignment Center and would anchor any future monitoring.

Verification link: https://assignmentcenter.uspto.gov/ (search by patent number 8,934,610); legacy interface: https://assignment.uspto.gov/patent/index.html

Method caveat: this conclusion rests on the USPTO-derived legal-events record plus Hitachi corporate filings. I could not query PACER/Docket Navigator, Patent Center fee history, or the rendered Assignment Center record directly in this session, and the correspondent-of-record field was not retrievable. The absence of a 12th-year fee event as of 2026-09-28 is most likely feed lag and should be confirmed in Patent Center before being relied upon.

I'll verify the patent record and research each cited prior-art reference before analyzing anticipation.

Now let me research the remaining cited references.

Prior-Art Analysis — US 8,934,610 B2 ("File management system, method and computer program")

0. USPTO record verification (number-specific, not similar-number)

I searched for the exact string 8934610 / US8934610B2. The record I could reach (Google Patents, which mirrors USPTO bibliographic data; Justia; EPO Global Patent Index) all describe the same single patent — there is no ambiguity with similar numbers:

• US 8,934,610 B2; Application 14/102,804; filed 2013-12-11; granted 2015-01-13; priority JP 2012-271415 (2012-12-12).
• Inventors Toshiaki Koyama; Toyoki Yamagishi; assignee Hitachi Information & Telecommunication Engineering, Ltd.
• Pre-grant pub. US 2014/0161238 A1; EP family EP 2744185 A1; JP family JP 6013895 B2.
• Source checked: https://patents.google.com/patent/US8934610B2/en ; https://patents.justia.com/patent/8934610 ; http://data.epo.org/pise-server/rest/collections/lgpi/EP2744185A1.pdf

This section builds on, and does not repeat, the previously generated patent summary and the (negative) litigation summary.

1. Legal framework applied

US 14/102,804 was filed 2013-12-11, i.e., after the March 16, 2013 AIA date, so AIA 35 U.S.C. §102 governs. The effective filing date is the JP priority date, 2012-12-12. For a reference to anticipate under §102(a)(1)/(a)(2), it must predate 2012-12-12 (or, for a US patent/application, be "effectively filed" before that date). All of the references below predate the critical date by many years, so timing is not an issue. The issue is disclosure, not date.

Key element to keep in view for every mapping. Each independent claim (1, 7, 9, 10, 11) requires the second device to:

"further acquire a second attribute information associated with the first attribute information from a third device different from the first device."

That "third-device enrichment" limitation is the pivot for §102, and no cited reference discloses it. This is consistent with — and reinforces — the previously generated scope observation that the independent claims are built around the attribute-first / file-later sequence plus third-party attribute enrichment (the transfer-timing and "local cash" features being specification-only).

2. Reference-by-reference analysis

A. JP 2010-219734 A — (the single most relevant reference)

• Full citation: JP 2010-219734 A, "Centralized control system for call recording" (通話録音集中管理システム); inventor Toshimitsu Aramaki; assignee Hardis System Design Co., Ltd.; JP App. 2009-062558.
• Filing / publication dates: filed 2009-03-16; published 2010-09-30. (Predates 2012-12-12.)
• Description: Distributed offices (departments/sales offices/branches) each hold a local server that, for each call, creates a voice file and an attribute file containing call start time, call end time, an identification code, the line number, and call duration, and stores them in a storage unit. The local servers are connected via a WAN to a central management server at the head office, which receives and stores the voice files so calls can be centrally managed. Motivated expressly by bandwidth/security problems of distributed recording.
• Potential §102 mapping: This is the closest art and the reference the examiner/EPO actually leaned on (EP search report categorization below). It plausibly discloses the first-device-side elements of claims 1, 7, and 11 (create record file; create first attribute information; store file with identifying information; transmit attribute over the network) and the generic center-side elements ("receives the record file… stores… manages"). It also touches claim 6 (management of an identification code + storage location).
• Where it falls short of anticipation: It does not disclose the second device "further acquir[ing] a second attribute information… from a third device different from the first device." Its attribute file is generated locally and sent with/alongside the voice file; there is no PBX/call-control-server/customer-server enrichment step. Accordingly it cannot anticipate independent claims 1, 7, 9, 10, or 11 as a whole, and because dependent claims 2–6 incorporate all claim-1/claim-2 limitations, it cannot anticipate those either. Its real role is as a §103 base reference (see EP categorization "[YD]"), not a §102 anticipation.
• Source: https://patents.google.com/patent/JP2010219734A/en

B. US 6,252,947 B1 — Diamond (Dictaphone)

• Full citation: US 6,252,947 B1, "System and method for data recording and playback"; inventor David A. Diamond et al.; assignee Dictaphone Corporation; App. 09/328,295.
• Filing / issue dates: filed 1999-06-08; issued 2001-06-26.
• Description: Recording and playback of telephone-call data segments stored across one or more playback servers; a CTI server supplies call context (start/end of call), so recording is managed "call-centric"; a database relates each call record to the location(s) of its recorded audio so segments can later be retrieved and played back in order.
• Potential §102 mapping: Relevant to the concept of a record file, attribute/call data tied to a stored recording, and a storage-location reference used to fetch the recording later — i.e., the general architecture underlying claims 1, 7, 9 ("receives the record file… stores…") and claim 6 (identification + storage address).
• Shortfall: No "second attribute information from a third device different from the first device," no two-device local→center upload with attribute-first sequencing as claimed. Cannot anticipate the independent claims; at best supports a §103 combination.
• Source: https://patents.google.com/patent/[US6785369B2](/patent/US6785369B2)/en (family record listing US09/328,295 → US 6,252,947 B1)

C. US 2002/0035616 A1 — Diamond (Dictaphone) [same family as B]

• Full citation: US 2002/0035616 A1, publication of App. 09/876,954 (continuation of US 6,252,947), "System and method for data recording and playback"; assignee Dictaphone Corporation; the application later issued as US 6,785,369 B2.
• Publication date: 2002-03-21.
• Description: Same disclosure as B — segment playback across playback servers, call-centric recording, database relating calls to stored audio segments.
• Potential §102 mapping / shortfall: Identical to B. Noteworthy because it is the reference the European Search Report expressly cited as "[Y]" against the EP sibling (EP 2744185), i.e., as a secondary (obviousness) reference, not as an anticipation reference.
• Source: EP search report text at http://data.epo.org/pise-server/rest/collections/lgpi/EP2744185A1.pdf

D. US 7,203,288 B1 — Dwyer et al. (Dictaphone)

• Full citation: US 7,203,288 B1, "Intelligent routing of voice files in voice data management system"; inventors John J. Dwyer, David K. Godin, Stephen Rothschild, John J. Pawlowski; assignee Dictaphone Corporation; App. 09/190,536.
• Dates: priority 1997-11-21; filed 1998-11-12; issued 2007-04-10.
• Description: A portable digital voice recorder generates voice files with header data (time/date stamp, type, length, compression algorithm, folder, title/ID, author/unit ID, status, link, source, priority, recipient info). A personal computer reads the header data and automatically forwards/routes the voice file to another device (central dictation system, voice-mail, etc.) based on the header data.
• Potential §102 mapping: Directly relevant to claim 1's "creates a first attribute information indicating attribute about the record file," and to the notion of transfer control based on attribute data (the specification's transfer-control theme, though not claimed) — and to claim 3's attribute-associated-then-file-transfer sequence in a general sense.
• Shortfall: No center device that acquires a second attribute information from a third device; no management table merging local + third-party attributes. Not an anticipation of any independent claim; a §103-support reference.
• Source: https://patentimages.storage.googleapis.com/62/b3/9b/27e0671ad4be9a/US7203288.pdf ; https://insight.rpxcorp.com/patent/[US7203288B1](/patent/US7203288B1)

E. US 2006/0242208 A1 — Goldick (Microsoft)

• Full citation: US 2006/0242208 A1, "Method and system for creating and maintaining version-specific properties in a file"; inventor Jonathan S. Goldick; assignee Microsoft Corporation (continuation of App. 11/448,529, later issued as US 7,849,054 B2).
• Dates: priority 2000-12-27; published 2006-10-26.
• Description: A file system creates and maintains a version-specific attribute/property stored as part of a file, containing version information, that is automatically invalidated on a predetermined update event; third-party applications create and read these attributes so that external logs/databases are unnecessary.
• Potential §102 mapping: Relevant only to the generic notion of file "attribute" information stored in association with a file (a possible mapping to claim 2's "attribute file creation unit" in the abstract).
• Shortfall: It is a local file-system metadata invention; it has no voice/image record file over a network, no first/second device upload split, and no third-device second-attribute acquisition. It does not anticipate any claim of US 8,934,610. It was most likely cited as background for the term "attribute/property."
• Source: https://patents.google.com/patent/US20060242208 ; https://patentimages.storage.googleapis.com/e1/ac/03/69fe5d726ec1e6/US7849054.pdf

F. US 2013/0083903 A1 — Raytheon BBN Technologies

• Full citation: US 2013/0083903 A1, "Systems and methods for presenting end to end calls and associated information"; assignee Raytheon BBN Technologies Corp.
• Dates: priority 2005-02-22; published 2013-04-04.
• Description: Presenting end-to-end calls together with associated information (call detail / call metadata), i.e., associating contextual call information with a call for display/search.
• Potential §102 mapping: Relevant only to the generic idea of associating call information (attribute data) with a call record. It does not disclose a local/center two-device architecture, attribute-first-then-file transfer, or third-device second-attribute acquisition. Not an anticipation of any independent claim.
• Source: as listed on https://patents.google.com/patent/US8934610B2/en (Citations)

G. JP 2002-064639 A — Hardis System Design (family citation)

• Full citation: JP 2002-064639 A, "Call-recording system for business for replying by telephone, and voice-recording board used by call-recording system"; assignee Hardis System Design Co., Ltd.
• Dates: filed 2000-08-17; published 2002-02-28.
• Description: A telephone-business call-recording system and associated voice-recording board — i.e., the basic local call-recording appliance art cited in the JP family/prosecution history.
• Potential §102 mapping: Generic call recording only; no center/second-attribute architecture. Not an anticipation.

H. JP 4099515 B1 — Digital Technology KK (family citation)

• Full citation: JP 4099515 B1, "Call recording device and voice aggregation device using network"; assignee デジタルテクノロジー株式会社 (Digital Technology Co., Ltd.).
• Dates: filed 2007-05-08; registered/issued 2008-06-11.
• Description: A networked call-recording device and a voice-aggregation device — aggregated collection of recorded calls over a network.
• Potential §102 mapping: Relevant to the generic concept of network aggregation of recorded voice files (center-side collection). No second-attribute-from-third-device feature. Not an anticipation.

I. Non-patent citation — European Search Report

• Citation: European Search Report for EP 13005777.1-1862, mailed 2014-04-28.
• Significance: This is the EPO's search opinion on the EP sibling (EP 2744185 A1). It categorizes JP 2010-219734 A as "[YD]" and US 2002/0035616 A1 as "[Y]" — i.e., both are cited as obviousness (Y) references, which are combined, not as X (anticipation) references. This is empirically consistent with my conclusion below.
• Source: http://data.epo.org/pise-server/rest/collections/lgpi/EP2744185A1.pdf

3. Synthesis — ranking and §102 conclusion

Bottom line on §102: For every cited reference, the reason it cannot anticipate is the same structural gap — none discloses the second device acquiring a second attribute information associated with the first attribute information from a third device different from the first device. Every independent claim of US 8,934,610 (system claim 1; method claim 7; center-only system claim 9; center-only method claim 10; CRM claim 11) contains that limitation, and every dependent claim (2–6) incorporates it. Therefore no cited reference is a §102 anticipation of any claim; their combined§103 relevance is real but individually they are background/obviousness references. This aligns with the fact the patent issued with all claims intact and with the EPO categorizing the two closest references as "Y," not "X."

Most relevant single reference: JP 2010-219734 A — the only cited art that discloses the local-server-created voice file + attribute file (call start/end, identification code, line number) stored locally and uploaded over a WAN to a central management server, which maps to the first-device-side steps of claims 1/7/11 and the management data of claim 6.

4. Explicit uncertainty / limits

• I confirmed the bibliographic record of US 8,934,610 via Google Patents/Justia/EPO, which mirror USPTO data; I could not open USPTO PatentCenter/Public PAIR directly, so I cannot certify the complete examiner-cited list beyond what is reproduced on the patent's face and on the Google Patents "Citations" table used above.
• I did not retrieve the full claim-by-claim text of US 2013/0083903 A1, JP 2002-064639 A, or JP 4099515 B1; my descriptions come from their titles/abstract-level data as reproduced in the patent's citation and family-citation tables. Conclusions for those three rest on title/abstract-level disclosure.
• US 9,471,592 B2 and US 9,400,804 B2 (same title as the patent, in "Similar Documents") and EP 2713589 B1 (Hitachi, priority JP 2012-212812) are same-family/same-assignee continuations, post-dating the critical date as publications; they are not third-party prior art to US 8,934,610 and are excluded from the anticipation analysis. (EP 2713589 has an earlier priority, 2012-09-26, but is commonly-owned sibling material, so AIA §102(b)(2)(C) common-ownership would remove it from prior art anyway.)
• If you can grant additional search steps, I can pull each reference's full claim set to convert the "potential §102" mappings above into a formal element-by-element anticipation chart.

I'll research the specific prior-art references cited on this patent's page to ground the § 103 analysis in their actual disclosures.

Let me pull details on the remaining cited references (the Microsoft application and the two Japanese family citations).

Obviousness Analysis — U.S. Patent No. 8,934,610 B2 under 35 U.S.C. § 103

This section builds on the claim summary and scope observations already generated. The single most important cross-reference is this: the independent claims (1, 7, 9, 10, 11) are directed to the attribute-first / file-later architecture plus third-party enrichment of attribute data, and do not recite the transfer-timing / reference-frequency / "local cash" logic that dominates the specification. That scope fact drives the entire § 103 analysis below.

1. Governing framework and assumptions

Governing law. The application (US 14/102,804) was filed 2013‑12‑11 but claims a foreign priority date of 2012‑12‑12 (JP 2012‑271415). Because every claim has an effective filing date before 2013‑03‑16, the pre‑AIA version of §§ 102/103 governs, and the KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007) framework applies (expansive combination jurisprudence; no rigid teaching‑suggestion‑motivation requirement).

Antecedent claim construction of the load‑bearing terms:

Person of ordinary skill in the art (PHOSITA). As of December 2012: a bachelor's degree in computer science/electrical engineering (or equivalent) with 2–4 years of experience in telephony call recording, IP‑PBX/CTI integration, or networked voice/image file management. This person is familiar with PBX/CTI links, RTP media capture, WAN file transfer, and relational/database record management.

2. The prior art on the face of the patent

All five references below appear in the "Citations" section of US 8,934,610 on Google Patents (https://patents.google.com/patent/US8934610/en) and are pre‑AIA § 102(b)/(e) art relative to the 2012‑12‑12 priority date:

Two further documents appear under "Family Cites Families" and are confirmatory only: JP 2002‑064639 A (Hardis, call‑recording system) and JP 4099515 B1 (Digital Technology, "Call recording device and voice aggregation device using network").

3. What the primary reference discloses — and where the gap is

JP 2010‑219734 A (https://patentimages.storage.googleapis.com/f5/0b/ee/ea3a9134523c20/JP2010219734A.pdf) discloses, per its published claim 1 and abstract:

• Telephone terminals at each decentralized office connected to a public telephone network;
• A local server at each office that, for each call, creates a voice file and an attribute file containing "call start time, call end time, identification code, line number, and call duration," and stores them in a memory;
• A central management server in the main office, connected to the local servers over a WAN, that receives and stores the voice files;
• The attribute file is given a local‑server ID and both the voice file and attribute file are sent to the central server and registered in a database;
• A search/replay client terminal networked to the central server that searches the database on attribute‑file items and retrieves the voice file by file transfer from the central server.

Mapping to claim 1: Hardis discloses elements 1.1–1.6, 1.8 (a database holding the attribute file), 1.9–1.10 (center receives and stores the voice file), and 1.11 in substance (database registration keyed to the record). Its explicit statement of purpose — "in order to enhance the convenience of search when playing back the voice file" (検索の利便性を高めるため) — is important: it supplies the design incentive the obviousness analysis needs.

The gap: Hardis creates the attribute file at the local server from the call itself. It does not disclose the second device acquiring "second attribute information … from a third device different from the first device" (element 1.7) — i.e., a separate source such as a PBX, CTI/call‑control server, or customer server. That single limitation is the crux of the obviousness case, and it is squarely met by the Dictaphone art.

4. Ground 1 — Independent claims 1, 7, 9, 10, 11: Hardis in view of US 6,252,947 B1 (and US 2002/0035616 A1)

4.1 What the secondary reference teaches

US 6,252,947 B1 (https://patents.google.com/patent/US6252947) is a call‑center recording/playback system. For § 103 purposes its material teachings are:

• Recording units capture call audio; a CTI link from the PBX supplies metadata to a separate computer: "the telephone numbers of parties involved in the call; Caller ID (CLID) or Automatic Number Identification (ANI); Dialed Number Identification Service (DNIS); or the Agent ID Number of the Customer Service Representative."
• The system "combin[es] the recorded digitized audio … with descriptive information ('metadata') obtained through a Computer Telephony Integration (CTI) communications link with the PBX, and store[s it] as a single manageable unit."
• It builds a "master call record" that "contains data matching each call with the segments of which it is comprised, and matching the data for each segment with the location of the recording of that segment," to facilitate search and retrieval.
• Recordings may be stored in different locations and managed by different playback servers, and the call record is used to assemble playback.

4.2 The combination and motivation

Motivation (four independent KSR rationales):

1. Known technique to improve a similar device in the same way (KSR, rationale C). Hardis expressly seeks to make its central database easier to search. '947 teaches that CTI‑supplied metadata from the PBX materially improves search/retrieval. A POSITA seeking to improve Hardis's search convenience would predictably apply '947's CTI‑metadata enrichment to Hardis's central database.
2. Simple substitution of one known element for another (KSR, rationale B). Hardis's locally generated attribute items (line number, identification code) are the same kind of data '947 obtains from the CTI/PBX link; substituting a richer, PBX‑sourced attribute feed for the locally derived fields is a predictable substitution.
3. Combining known elements according to known methods, predictable result (KSR, rationale A). Both systems are standard call‑center recording architectures; joining "central archival over a WAN" (Hardis) with "CTI metadata enrichment" ('947) yields no more than the expected sum of their parts — searchable, centralized call records.
4. Design incentive / market pressure (KSR, rationale F). The patent's own Background frames the problem — collect record files centrally for security, but avoid WAN congestion — and states that wide‑area, attribute‑based search is desired. That market pressure supplies the motivation.

Reasonable expectation of success. Both references are in the same field and rely on the same off‑the‑shelf building blocks (PBX/CTI interface, WAN, database). Integrating CTI metadata into a central call‑records database was routine by 2012 (the patent's own specification says the local device may "monitor and analyze the call control packet from the PBX" or "acquire information which the telephone system 21 keeps through a CTI link"). Success was predictable.

Claim 7 is the method counterpart and rises and falls with claim 1. Claims 9 and 10 (center‑only system/method) add the temporal phrase "after acquiring the first attribute information, receives the record file." Hardis transmits and registers attribute data at the center; and US 7,203,288 B1 (Ground 2) expressly teaches using the header/attribute data to decide whether and when to forward the voice file — supplying exactly this sequencing. Claim 11 (non‑transitory CRM) is the software incarnation of the same architecture; under In re Beauregard and KSR, a claim to a storage medium that, when executed, performs an obvious process is itself obvious — no separate inventive contribution is recited.

5. Ground 2 — Claim 3 (and the sequencing of claims 9/10): + US 7,203,288 B1 (Dwyer, Dictaphone)

US 7,203,288 B1 (https://patents.justia.com/patent/[7203288](/patent/7203288); PDF at https://patentimages.storage.googleapis.com/62/b3/9b/27e0671ad4be9a/US7203288.pdf) claims a system in which "the personal computer reads said header data transferred to the personal computer and uses said header data to determine whether to transfer the corresponding voice data file to said other information processing device," where the header data is "indicative of … (a) an identity of said portable digital audio recorder; (b) a subject matter of the voice data file …; and (c) a work type of the voice data file."

Claim 3 requires that the first device transmit the first attribute information first, then transfer the record file, and that the center flip the record to "reception finished." '288's header‑driven, condition‑based forwarding decision teaches a POSITA to (i) attach attribute/header data to a voice file, (ii) transmit that attribute information across the network, and (iii) gate the subsequent media transfer on it — then record that the transfer occurred. Motivation: '288 and Hardis share the identical problem of managing voice‑file traffic to a central device; a POSITA would apply '288's routing logic to schedule Hardis's WAN uploads. This is also the closest art to the patent's "transfer control condition" (spec FIG. 12) and the spec's own background concern about network load.

6. Ground 3 — Claims 4 and 8: Hardis + '947 (explicit PBX / call‑control‑server limitation)

Claim 4 and claim 8 narrow "third device" to "a PBX or a call control server in the telephone system." This is met directly and explicitly by '947, which describes the CTI link to the PBX and the metadata it supplies (ANI/DNIS/agent ID). No additional reference is needed once the Ground 1 combination is made; the dependent claim merely makes express what Ground 1 supplies. The combination motivation, expectation of success, and reasoning are identical to Ground 1.

7. Ground 4 — Claim 5: "customer server as the third device" (Hardis + '947 + US 2013/0083903 A1 (Raytheon BBN))

Claim 5 substitutes, as the third device, "a customer server which manages information of customers who are possible to call in the telephone system." This is the weakest of the grounds.

• US 2013/0083903 A1 (https://patents.justia.com/patent/20130083903) is a call‑center performance‑analysis system: it "confirm[s] that the audio records of a plurality of calls have been received by the center," analyzes the audio, and derives "call propert[ies]" including "a caller phone number, a date of the call, a time of the call, the duration of the call, or the time the call was routed to a live agent," with a browseable UI and playback. It is a § 102(e) reference as of its 2005‑02‑22 priority.
• Motivation/expectation: '903 evidences that enriching call records with externally supplied call properties for analysis was conventional in call‑center practice, and the patent's spec itself shows that combining recording data with a customer‑management server is the kind of routine CRM integration a POSITA would implement. But '903 does not clearly disclose querying a separate customer‑management server to pull customer name / contract‑conclusion flag / complaint flag.
• Assessment: The customer‑server limitation is arguably supported by general knowledge of CTI‑to‑CRM integration (a well‑known coupling in call centers), which under KSR can supply a missing limitation where the improvement is predictable. But because no cited reference squarely discloses it, claim 5 is the most defensible of the claims against a § 103 challenge built only on the references on the face of the patent. A petitioner would likely need to add a CRM‑integration reference or rely on official notice / general knowledge — a step that invites a "no evidentiary support" rebuttal.

8. Ground 5 — Claims 2, 6, 11 (structural / table / CRM): + US 2006/0242208 A1 (Microsoft, Goldick)

US 2006/0242208 A1 (granted as US 7,058,667 B2 and US 7,849,054 B2; see https://www.patents-review.com/a/20060242208-method-system-creating-maintaining-version-specific-file.html) discloses file attributes/properties that are "stored as part of a file in a file system," "contain specific version information relating to how or when the attribute was created," and are "automatically invalidated when a predetermined 'update' event occurs … to thereby eliminate the need for external logs or databases to store persistent state information."

• Claim 6 (management table with a record‑file ID, an address specifying the first storage unit, and a reception flag): Hardis supplies the DB keyed on identification code and local‑server ID; '947 supplies the "location of the recording" field (the storage‑location address); '208 teaches automatic state tracking of attributes (a reception/validity flag) updated on a predetermined event. Motivation: tracking whether a file has been received and where it resides is standard database bookkeeping, and '208 explicitly addresses automating such state updates. Predictable result.
• Claim 2 is a structural recitation of the claim‑1 devices (creation units, storage units, transfer/management units). Under KSR, reciting the components that perform the already‑obvious steps adds nothing patentable.
• Claim 11 (CRM): see Ground 1; no separate contribution.

9. Rebuttal considerations the patent owner would raise (and their weight)

9.1 Teaching away — weak. None of the cited references teaches away from enriching a central call‑records database with separately sourced attribute data. Hardis's stated goal ("enhance the convenience of search") favors it. No reference disparages the combination.

9.2 "The center acquires the second attribute info over the network from a remote third device" — moderate. '947 locates the CTI/PBX metadata acquisition at the call center, where metadata is combined with the recording before it reaches central storage. The patent places the second attribute acquisition at the center device, reaching back over the WAN to a PBX/call‑control/customer server. This is a genuine architectural difference, but it is a difference of where a query is sent, not in the data or result; under KSR (and In re KSR‑era "obvious to try" reasoning) relocating a data‑gathering step to the node that needs the data — while preserving the network — is a predictable design choice. Weight: low‑to‑moderate.

9.3 Claim 5's customer‑server limitation — the strongest defense. As noted in § 7, no cited reference squarely discloses acquiring second attribute information from a customer‑management server that stores customer name/contract/complaint data. Weight: moderate‑to‑strong for claim 5 only.

9.4 The "attribute‑first, file‑later" sequence — weak‑to‑moderate. Claims 1 and 7 do not impose a strict order; claims 9/10 do ("after acquiring the first attribute information"). Hardis transmits attribute and voice files together, so the sequence is not squarely taught by Hardis. However, '288 supplies the header‑driven deferred‑transfer teaching that renders the sequencing obvious.

9.5 Secondary considerations (objective indicia). The record reveals no evidence of unexpected results, long‑felt but unsolved need, failure of others, copying, or a nexus‑bearing commercial success attributable to the claimed combination. The patent's own Background characterizes the core centralized‑management approach as known in the art and frames the problem as one of bandwidth/latency management. Absent objective indicia, the KSR combination analysis is not rebutted.

9.6 Claim‑scope caution (worth flagging). Note that the transfer‑timing / reference‑frequency / "local cash" subject matter — the patent's headline advance — appears in sibling filings (e.g., EP 2744184 A1 / JP 2014‑116893 A, whose claims recite "transfer condition" and a "cash flag"), but is absent from US 8,934,610's independent claims. This corroborates that the US independent claims are the narrower, architecture‑only claims and thus more exposed on § 103, since the features that might have supplied non‑obviousness are not claimed.

10. Bottom‑line assessment

Overall. On the references cited on the face of US 8,934,610, independent claims 1, 7, 9, 10, and 11 and dependent claims 2, 3, 4, 6, and 8 are, in my assessment, more likely than not obvious under pre‑AIA § 103 as KSR is applied, with JP 2010‑219734 A as the primary reference and US 6,252,947 B1 supplying the third‑party (PBX/CTI) attribute‑acquisition limitation. Claim 5's customer‑server source is the only limitation for which the cited art does not provide a clear teaching, and it would require either an additional reference or reliance on general CRM‑integration knowledge — making claim 5 the locus of any successful non‑obviousness argument.

Confidence and caveats. This analysis is based on the references listed on the patent's Google Patents page and their publicly available abstracts/claims as fetched today; I did not obtain or review the full prosecution history (the file wrapper), the European Search Report cited as the sole "Non‑Patent Citation," or an examiner's reasons for allowance. Two of the secondary references — US 7,203,288 B1 and US 2006/0242208 A1 — are Dictaphone/Microsoft documents from the 1997–2006 era, well before the 2012 priority date, which is favorable to a § 102(b) challenge but means their factual teachings should be confirmed against full‑text passages (column/paragraph cites) before being asserted in a formal petition. I flag that I could not retrieve the full text of JP 2002‑064639 A or JP 4099515 B1 (the "Family Cites"), so those are treated as confirmatory background only.