US 9661057

I'll search for the specific patent and check for any litigation/docket activity.

Let me check for any litigation/docket records and try to retrieve the claims text.

US Patent 9,661,057 B2 — Summary

Important caveat up front: The searchable full text I retrieved for this patent (including the Google Patents page, which is the authoritative source served here) contains the front matter, abstract, description, and figures list, but not the verbatim claim set. So the claim overview below is reconstructed from the patent's own "Definitions" section, the Abstract, and the Summary of the Disclosure — not from transcribed claim language. I could not retrieve an authoritative claim-by-claim text in this session.

Bibliographic data

Abstract (as listed)

"A transmission management system includes a destination name data managing unit which manages a plurality of destination name data items which indicate a plurality of names of a destination in communications between transmission terminals, a destination name data reading unit which reads a destination name data item from the plurality of destination name data items managed by the destination name data managing unit, and a destination name data transmitting unit which transmits the destination name data item read by the destination name data reading unit to a transmission terminal capable of communicating with the destination."

Technical context

The patent is set in a videoconference ("transmission") system: terminals 10 communicate via a relay device 30, managed by a transmission management system 50. It addresses a stated problem in the prior art (cited: Japanese Laid-Open Patent Publication No. 2012-050063) that only a single, common destination name was used per destination, whereas the "easy-to-specify" name may differ by context (e.g., team names within one organization vs. company names between organizations).

Plain-language overview of the disclosure's claim concepts

Based on the patent's own functional definitions, the invention is built around a destination name data managing unit 5010 that holds multiple different display names for the same single destination, and logic that picks the appropriate one. Three data sources are described:

• First destination name data — managed in a destination list management table (FIG. 10), associated with a request-source terminal ID. E.g., a list of names offered to terminal "01aa" for destination "01ba" ("Osaka YY planning team", "Osaka BO, A Inc.").
• Second destination name data — managed in a reservation terminal management table (FIG. 11B), associated with a reservation ID, used for a scheduled meeting/reservation.
• Third destination name data — managed in a terminal management table (FIG. 12), a globally notifyable label (e.g., a telephone number) used when nothing else is available.

The described reading logic (FIG. 20, steps S53‑3 to S53‑8) has a fallback hierarchy: read the second (reservation-specific) name if present; if not, read the first (request-source-specific) name from the destination list table; and if that is also absent, read the third (generic) name. The apparatus then transmits the selected name to the terminal.

Given the title names three subject-matter categories, the patent most likely presents independent claims directed to (1) a transmission management system (the managing/reading/transmitting unit combination described above), (2) a transmission system incorporating such a management system, and (3) a non-transitory recording medium storing a program that causes a computer to perform the name-data selecting and transmitting process. I could not confirm the exact number, numbering, or wording of the independent claims from an authoritative source in this session.

Litigation / CAFC 2026 docket check — NEGATIVE RESULT

• Searches for "9661057" or "9,661,057" combined with litigation/docket/CAFC terms returned no Federal Circuit case, IPR, or district-court docket tied to this patent number. I found no CAFC 2026 docket entry for US 9,661,057.
• The Google Patents record carries a "Family has litigation" flag with a Darts‑IP link, indicating some litigation exists somewhere in the worldwide family — but that flag does not specify the patent, court, or party, and I could not substantiate it.
• One unconfirmed lead only: there is an active 2026 case, Ricoh Company, Ltd. v. Zoom Communications, Inc., No. 1:25-cv-01095, with 2026 filings (e.g., briefing docketed February–March 2026). I cannot confirm that US 9,661,057 is one of the patents asserted in that case — treat this as a lead to verify, not a finding.
• Separately, the search surfaced an unrelated 2021–2023 matter, Ortiz & Associates Consulting, LLC v. Ricoh USA, Inc. (W.D. Tex. 6:21‑cv‑01178), which concerned a different patent (US 9,549,285) and has no apparent connection to 9,661,057.

Uncertainty disclosure

• Claim text: not authoritatively retrieved (see caveat above).
• Litigation/CAFC 2026: no hit for this patent number; the Darts‑IP "family has litigation" flag is unsubstantiated as to specifics.
• Everything else (title, inventors, assignee, dates, abstract) is grounded in the Google Patents record provided and is consistent across the sources retrieved.

I'll search for litigation involving US patent 9661057.

Let me search more specifically across litigation databases.

The Zoom/Ricoh case appears relevant. Let me verify whether US9661057 specifically is asserted, and check litigation databases.

Litigation Search Results for US Patent 9,661,057

Bottom line: I found no confirmed litigation in which US 9,661,057 (the '057 patent) itself is an asserted patent-in-suit. Below is what my searches did and did not establish.

What the patent record itself indicates

• The Google Patents page for US 9,661,057 contains a "Family has litigation — First worldwide family litigation filed" flag, linking to a Darts-IP family record (family=50028107). This indicates that some member of the '057 patent's family has been the subject of litigation somewhere in the world. It does not identify the case, parties, jurisdiction, or which family member was asserted, and I could not resolve that record to a specific case involving the '057 patent itself from the sources available to me.
• Docket metadata: US 9,661,057 B2; App. No. 14/417,868; filed 2013-07-26; priority 2012-08-01; granted 2017-05-23; assignee Ricoh Company, Ltd.; inventors Kaoru Maeda and Takahiro Asai; anticipated expiration 2033-07-26. Note: litigation I located involves later, related Ricoh videoconferencing patents, not this one.

The closely related case I did find (does NOT assert the '057 patent)

Ricoh Company, Ltd. v. Zoom Communications, Inc. — D. Del., Case No. 1:25-cv-01095-JCG

• Plaintiff: Ricoh Company, Ltd.
• Defendant: Zoom Communications, Inc. (f/k/a Zoom Video Communications, Inc.)
• Jurisdiction: [U.S. District Court for the District of Delaware (Wilmington)](/courts/district-of-delaware-wilmington)
• Court: Chief Judge Colm F. Connolly / Judge JCG
• Filing date: August 29, 2025
• Asserted patents: U.S. Patent Nos. 10,904,487; 10,909,059; 10,931,917; 11,256,464; 11,289,093; 11,516,278; and 11,546,548. US 9,661,057 is NOT among the asserted patents.
• Status: Zoom moved to dismiss under Rule 12(b)(6) (§ 101); motion denied in part on May 1, 2026 — the court held the claims directed to abstract ideas at Alice step one but found Ricoh plausibly alleged inventive concepts at step two, so the case proceeds. (Ricoh Co., Ltd. v. Zoom Communications, Inc., No. 1:25-cv-01095-JCG (D. Del. May 1, 2026).)

Why this case is relevant to your patent: The Zoom case asserts Ricoh's '278 patent (11,516,278), which appears to be a later member of the same family/technology line as US 9,661,057 — the briefing discusses the '278 patent in terms that track the '057 specification almost verbatim, e.g., "easy-to-specify" destination names, a "destination list management database," an "operation input receiving unit," a "terminal management database," and updating a name. This strongly suggests the '057 patent sits in the same family that Darts-IP flags as having litigation, but the '057 patent itself was not pleaded in Ricoh v. Zoom, and I found no other case asserting it.

Caveats and limitations (stated explicitly)

• The public sources I could search (including via the litigation-oriented results returned) did not surface any complaint, PACER/CAFC docket, or Unified Patents entry naming US 9,661,057 as a patent-in-suit. The searches that returned results for "9661057" returned only unrelated patents (e.g., LifeScan '247/'862 patents, Immersion/Fitbit haptics patents), which I am disregarding as non-responsive to your specific number.
• I could not fully open the Unified Patents litigation caselist or the Darts-IP family record for family=50028107; those would be the authoritative places to confirm whether the '057 patent's family litigation involves the '057 patent itself.
• I cannot rule out (a) litigation that is not yet publicly docketed/indexed, (b) litigation in foreign jurisdictions indexed only in Darts-IP or similar proprietary databases, or (c) PTAB proceedings (IPR/PGR) that are not "litigation" in the district-court sense.

Recommended next steps to confirm: search the Darts-IP family record 50028107 directly; run a Unified Patents and PACER "party" search for Ricoh Company, Ltd. as plaintiff and for the exact patent number 9,661,057; and check USPTO Patent Center / PTAB for any post-grant proceedings on the '057 patent.

If you want, I can now attempt a deeper targeted search on the Darts-IP family ID and on any PTAB proceedings for US 9,661,057.

I'll start by checking web sources for any AIA trial activity on this patent, since the structured ODP block indicates none.

Important distinction: the search returned proceedings on US 9,666,105 (Ultravision Technologies, Samsung petitioner) — a different patent number from US 9,661,057. Let me run more targeted searches to be sure there's nothing on the Ricoh patent.

Let me run two final checks — one on Docket Alarm/CourtListener for this exact patent, and one on the Ricoh v. Zoom assertion to see whether the '057 patent is in suit.

⚠️ Patent-number confusion check (read first)

Before any analysis, a critical disambiguation. Web searches for "9661057" repeatedly return proceedings on US 9,666,105 — Samsung Electronics Co., Ltd. v. Ultravision Technologies, LLC, IPR2020-01176, filed 2020, challenging claims 15 and 17 of the '105 patent over Rycyna (U.S. Pub. 2013/0271973) alone and in further view of Smith (WO 2007/146821) and Minnick (U.S. 5,561,960), per the petition on Docket Alarm.

That is Ultravision's LED-display patent assignable to a completely different owner — it is not US 9,661,057 (Ricoh, "Transmission management system, transmission system, and recording medium"). The digit strings are one transposition apart (…6105 vs …1057). None of those Samsung/Ultravision filings, nor Fitbit's IPR2018-00588/-00590 series, touch the Ricoh patent. I am flagging this because it is the single most likely source of error in a PTAB clearance search on this number.

---

Proceedings overview

There are zero AIA trial proceedings on file against US 9,661,057. The structured PTAB block built from the USPTO Open Data Portal returns no IPR, PGR, or CBM petitions for this patent, and my independent web searches surfaced no petition, institution decision, FWD, or appeal naming US 9,661,057 or Ricoh's '057 patent in any PTAB context. Breakdown: active 0 / claims invalidated 0 / claims sustained 0 / settled 0 / institution denied 0.

Bottom-line defensive posture: the opposite of "hardened." This is an untested patent. No forum has construed its claims, no petitioner has tested its priority date (2012-08-01) against prior art, and no panel has validated or invalidated a single claim. A defendant today faces the original, un-narrowed claim set — which cuts both ways: there is no IPR estoppel and no adverse claim construction to leverage, but also no FWD you can hand the court and no cancellation to short-circuit a demand letter. Absence of PTAB activity is not evidence of strength; it is evidence that nobody has yet found it worth the filing fee.

Proceedings

None. No proceeding entries exist to report. I will not manufacture numbers, panels, or dispositions to fill this section. For completeness, here is what I could and could not verify:

• ODP structured block: no AIA trials — canonical and controlling.
• Independent search: no IPR/PGR/CBM referencing US 9,661,057.
• Nearest false positive: IPR2020-01176 (Samsung v. Ultravision, US 9,666,105) — different patent, different patent owner; do not cite it in any brief or opinion about the Ricoh patent.

Strategic summary

Claim status: entirely UNTESTED. Every claim of US 9,661,057 stands as issued on 2017-05-23. Nothing has been canceled, nothing has been confirmed, nothing has been construed by a panel. Because the specification describes three distinct destination-name-data tiers — first destination name data keyed to the request-source terminal ID in the destination list management table (FIG. 10), second destination name data keyed to the reservation ID in the reservation terminal management table (FIG. 11B), and third destination name data keyed to the destination terminal ID in the terminal management table (FIG. 12) — with a fallback cascade among them (FIG. 20, steps S53-3 through S53-7), any future validity attack would have to grapple with that tiered structure claim-by-claim, not as a monolith. But that is speculation about a fight that has not happened.

Estoppel landscape: nothing exists yet, in either direction. With no petitioner and no FWD, § 315(e)(2) estoppel is not triggered against anyone. That means a defendant's IPR window under § 315(b) is fully open — the one-year clock has never started because no complaint has been served on this patent (see the litigation note below). A would-be petitioner can raise any § 102/§ 103 ground over patents and printed publications, unconstrained by prior IPR art or arguments. Equally, there is no patent-owner-side prosecution disclaimer or IPR-driven amendment narrowing the claims, so claim scope remains as broad as the 2017 issuance.

Pattern signals: none on the PTAB side. No serial petitioner, no defensive aggregator (no Unified Patents, RPX, or similar filer), no Patent Owner appeal history, no Federal Circuit docket. The "family has litigation" flag on the Google Patents family page reflects district-court activity somewhere in this Ricoh videoconferencing family, not PTAB activity. On that front: Ricoh Company, Ltd. v. Zoom Communications, Inc. (D. Del., complaint filed August 2025; First Amended Complaint 2026-01-13; Zoom renewed a § 101 motion to dismiss under Alice) asserts a set of Ricoh patents — the '487, '059, '917, '464, '093, '278, and '548 patents, per the Delaware opinion. Note two things: (1) the asserted list does not include the '057 patent by its number; and (2) the '278 patent bears the identical title "Transmission Management System, Transmission System, and Recording Medium" and is a probable continuation-family relative, but it issued 2022-11-29 and is a different patent document — I cannot confirm it shares 9,661,057's claims, and it is not the patent you asked about. Separately, US 9,661,057 has at least one confirmed continuation, US 10,904,315 (issued 2021-01-25), which states on its face that it is a continuation of application 14/417,868 — the application that issued as 9,661,057.

Recommended next steps

• If you are a defendant being asserted against on US 9,661,057: treat this as a greenfield validity challenge. There is no FWD to quote and no cancellation to lean on — I cannot give you a "claim 1 is dead" line because no claim of this patent has ever been challenged. Instead, the actionable move is the standard open-window analysis: confirm your § 315(b) posture the moment you are served, and treat the 2012-08-01 priority date and the Japanese priority documents (JP 2012-171192, per the Chinese counterpart CN 104620571 A) as the art cutoff.
• If you are evaluating a licensing demand: demand-letter math here is unusually uncertain. The patent has never been tested, so a licensor cannot point to IPR survival as validation, and you cannot point to cancellation as leverage. Price the risk on the merits of the claims themselves, not on PTAB history.
• Verify before relying: two things I could not fully close out within this research pass and that you should confirm against primary sources — (a) whether any petition was filed against the '057 patent and terminated before the ODP ingest (search PTAB E2E by patent number, not by family); and (b) whether the '278 patent asserted in Ricoh v. Zoom is in fact a continuation whose claims mirror the '057 claims, which would let you piggyback on the § 101 fight in Delaware without ever filing an IPR. Flag: the ODP default of "no PTAB activity on file" is the answer I am giving, but it is a negative finding and therefore inherently subject to ingest lag.

I'll research the assignment record for US 9,661,057. Let me run several searches.

Let me dig deeper into assignment records, the Ricoh v. Zoom litigation lead, and any NPE activity.

I have a key litigation finding. Now let me verify assignment records and check for any post-issuance transfers.

Assignment & Ownership Analysis — US 9,661,057 B2

Method note (important): I could not retrieve the underlying assignment instrument data (reel/frame numbers, correspondent attorney, execution dates) for this patent in this session. The USPTO Assignment Center search interface is a dynamic query endpoint that did not return a machine-readable record page here, and the Google Patents legal-events block for US 9,661,057 discloses only the existence and recording date of a single assignment, not the reel/frame or correspondent. Where I lack data I say so rather than filling the gap. Everything below is grounded in the patent front matter, the Google Patents legal events, and the Delaware litigation record.

---

Inventors

Both inventors are Ricoh personnel; the patent is a straight employee-invention assignment, not an inventor-held or university-licensed asset. Independent lead: PatentLeaderboard lists Maeda with 22 patents, all Ricoh — a career in-house engineer profile, not a serial independent inventor.

Unusual-pattern check: No evidence of inventors departing Ricoh around filing. The prior analysis's "all inventors departing within 12 months" fire-sale precursor is not present — there is nothing to suggest inventor-side assignment activity at all.

---

Original assignee

Ricoh Company, Ltd. (Tokyo, Japan) — original and current assignee of record per Google Patents ("Current Assignee: Ricoh Co Ltd"). No re-assignment away from Ricoh appears anywhere in the record.

• Primary line of business: Ricoh is a diversified imaging/electronics conglomerate (founded 1936) — office imaging (MFPs), printing, industrial systems, and, relevantly here, cloud-based communication and collaboration services including videoconferencing, whiteboards and messaging, which it began offering in the early 2000s. This is directly on point: the patent's own FIG. 1/FIG. 2 architecture (terminal 10 / relay 30 / management system 50) is Ricoh's RICOH Unified Communication System videoconferencing product family.
• Product embodying the claims: Yes — Ricoh ships/commercializes videoconferencing and collaboration products in this exact space, as its own pleadings assert.
• Current status: Operating, publicly traded, no bankruptcy. Ricoh is affirmatively litigating its patent family (see below), which is inconsistent with a distressed or wind-down posture.

---

Assignment timeline

Chronological record of every known conveyance:

• Executed date: not retrieved / recorded 2015‑01‑28 — Reel not retrieved/not retrieved
  • Conveyance: Assignment (ASSIGNMENT OF ASSIGNORS INTEREST)
  • Assignor: ASAI, TAKAHIRO; MAEDA, KAORU (both, individually)
  • Assignee: RICOH COMPANY, LTD.
  • Correspondent: Not disclosed in the sources retrieved. I could not retrieve the recording attorney/firm of record. No recurrence can be established.
  • Context: Standard pre-issuance employment assignment of the inventors' rights to their employer. It coincides with the US national-stage entry date (2015‑01‑28); the underlying PCT was filed 2013‑07‑26.

That is the entire chain. There are no post-issuance assignments — no transfer to an IP holding company, no security agreement, no merger, no license recordation, no release/correction. Per the task framing, this is itself the finding: the original assignee, Ricoh, still owns the patent.

Supporting docket/ownership confirmation: Ricoh's own complaint in Ricoh Company, Ltd. v. Zoom Communications, Inc., No. 1:25‑cv‑01095‑JCG (D. Del.) states "Ricoh is the owner of all rights, title, and interest in the Asserted Patents." US 9,661,057 is not itself among the seven asserted patents, but it sits in the same family as asserted US 11,516,278, which carries the identical title — "Transmission Management System, Transmission System, and Recording Medium."

---

Timeline diagram

timeline
    title Ownership of US 9661057
    2013 : PCT application filed by Ricoh
    2015 : US national stage entry
         : Inventor assignment recorded to Ricoh
    2017 : Patent issued to Ricoh
    2022 : Family member US 11516278 issued
    2025 : Ricoh sues Zoom on family patents

---

NPE / troll-pattern signals

Note on the Google Patents "Family has litigation" flag: the prior section flagged a Darts‑IP "family has litigation" indicator. The Delaware record now explains that flag: the family is in suit (Ricoh v. Zoom), but the asserted patents there are US 10,904,487; 10,909,059; 10,931,917; 11,256,464; 11,289,093; 11,516,278; and 11,546,548 — not US 9,661,057. That is a genuine contradiction to avoid mis-stating: "family in litigation" ≠ "this patent asserted."

---

Verdict

Operating-company assertion.

The ownership chain consists solely of a standard employee assignment from inventors Maeda and Asai to Ricoh Company, Ltd., recorded 2015‑01‑28, with no post-issuance transfer of any kind. Ricoh still owns the patent, ships videoconferencing/collaboration products in the claimed space, and is currently asserting the same patent family (including identically titled US 11,516,278) against a direct competitor, Zoom, in Ricoh Co. v. Zoom Communications, Inc., No. 1:25‑cv‑01095 (D. Del., filed Aug. 29, 2025; §101 motion denied May 1, 2026). That is the textbook operating-company profile — zero NPE signals are present.

Caveat on precision: because only the original assignment is of record, a strict reading of the rubric's "Insufficient data (… only the original assignment)" category also fits. I have chosen Operating-company assertion because the affirmative evidence — an operating assignee with products on the market and active, self-funded assertion against a competitor — resolves the ownership question rather than leaving it open.

Verify at: USPTO Assignment Center — https://assignmentcenter.uspto.gov/ (search patent number 9661057), legacy interface https://assignment.uspto.gov/patent/index.html. Litigation record: https://www.courtlistener.com/docket/71231937/ricoh-company-ltd-v-zoom-communications-inc/ ; Google Patents: https://patents.google.com/patent/US9661057/en.

Two disclosure items I could not resolve and am not estimating: (1) reel/frame numbers and the recordation correspondent; (2) any security-interest or license records that may exist but are not surfaced in the legal-events block. If you need these, the Assignment Center "abstract of title" view for patent 9661057 is the authoritative pull.

I'll search the USPTO database and related sources for the specific patent number 9661057 and its cited prior art.

Let me get the citation data directly from patent databases.

I found the citation list. Let me retrieve the complete list of cited references.

I've gathered what I can. Before the findings, two important process notes.

Scope, sources, and a hard limitation

• Patent verified literally: US 9,661,057 B2, "Transmission management system, transmission system, and recording medium," App. No. 14/417,868, filed 2013‑07‑26, priority 2012‑08‑01, granted 2017‑05‑23, Ricoh Company, Ltd.; inventors Kaoru Maeda and Takahiro Asai. This matches the number you asked for; I did not substitute any similar number. (Search hits for unrelated patents such as LifeScan's '247/'862 or Immersion/Fitbit haptics were discarded as non‑responsive.)
• Primary source: Google Patents (the authoritative record served here), supplemented by web search. I did not directly open USPTO Patent Center / PTAB full‑text in this session.
• Hard limitation (carried forward, unchanged): I still could not retrieve the verbatim claim set of US 9,661,057 from any authoritative source. The pre‑grant publication is US 2015/0215368 A1. Because the task asks which claim(s) a reference "potentially anticipates under § 102," and I don't have the literal claim language or numbering, every claim‑number mapping below is provisional and cannot be confirmed. I state this plainly rather than inventing claim numbers.

The patent's own citation data — what I could and could not confirm

The Google Patents page for US 9,661,057 carries a citation listing. I recovered the first entries verbatim from the US9661057 page itself (patents.google.com/patent/US9661057#7), which showed the label "Citations (15)" beginning with the three items below. I also recovered a longer list under a "Patent Citations (26)" header from a related Ricoh page (US12368769) that cites the '057 patent. These two counts conflict (15 vs. 26), and I could not fully disambiguate which entries belong to the '057 patent versus the related page — so treat entries 4 onward below as provisionally attributed and verify them directly.

The single reference I can confirm from the patent's own specification text is Japanese Laid‑Open Patent Publication No. 2012‑050063 (cited in the Background Art section as the known transmission management system).

Cited references (provisional list) and provisional § 102 relevance

Reminder: § 102 requires a single reference to disclose every limitation. Nothing below is a confirmed anticipation finding; these are candidate references and the elements each could plausibly supply. Exact claim numbers are unverified.

(Note: The above is the list I could assemble. It may be incomplete relative to the "26" figure, and I did not retrieve a "Non‑Patent Citations" or "Cited By" list.)

Which prior art is most relevant

Ranked by proximity to the '057 core concept ("manage multiple names for one destination, read one, transmit it to the terminal"):

1. US 2009/0177974 A1 (Cox) — multiple profiles/identities in a synchronous conferencing environment. The closest match to "a plurality of destination name data items for a single destination." Best § 102 candidate.
2. JP2012050063A / US 8,782,229 B2 (Ricoh) — the admitted background art; supplies the destination‑list‑generation and transmission‑to‑terminal elements, but (per the '057 specification) only a single common name, so it likely cannot alone anticipate the multi‑name limitation.
3. JP2005202891A (Just Syst) — "destination name" management/shaping for messaging; the most on‑point "destination‑name" reference outside conferencing.
4. US 2002/0138650 A1 (Yamamoto) — context/location‑dependent terminal naming; examiner‑flagged.
5. JP2011205612A, JP2012134944A, JP2012138893A, US 2012/0140022 A1 — related Ricoh transmission‑management art; collectively strong § 103 combination material.

JP2011164488A (optical scanner) has no apparent technical relationship to the claimed subject matter; I would not count it as prior art of interest.

Flagged inconsistencies (per your cross‑reference instruction)

1. Claim text gap (carried forward, not resolved): the prior sections and this one both note that the verbatim claims of US 9,661,057 were never retrieved. This directly limits any § 102 claim mapping. I did not paper over it with invented claim numbers.
2. Citation‑count conflict: Google Patents' '057 page showed "Citations (15)" while a related Ricoh page (US12368769) showed "Patent Citations (26)" with overlapping entries. One of these may belong to the related page, not the '057 patent. Verify on the live page.
3. Date contradiction in the provided materials: your current‑task header states April 26, 2026, and the system context states 2026‑09‑30, while the previously generated litigation summary asserts a May 1, 2026 motion‑to‑dismiss ruling in Ricoh v. Zoom (No. 1:25‑cv‑01095‑JCG). Those dates cannot all be simultaneously correct; I flag it rather than silently reconciling. I also cannot confirm the '057 patent is asserted in that case (the prior litigation section itself found it was not among the pleaded patents).

Bottom line: US 9,661,057 is confirmed; its cited references center on Ricoh's own earlier videoconference transmission‑management patents plus a small set of name/profile references. The most relevant prior art for a § 102 argument is US 2009/0177974 A1 (multiple conferencing profiles) and the admitted background art JP2012050063A / US 8,782,229 B2. Confirming which specific claims these could anticipate requires the verbatim claim set, which remains unretrieved. Recommended next step: pull the '057 claims from USPTO Patent Center (App. No. 14/417,868) and re‑run the element‑by‑element § 102/§ 103 mapping against the above references.

I'll research the prior art references available for this patent, starting with the reference cited in the patent itself.

I found a highly relevant prior-art reference. Let me investigate it and retrieve the full claim set.

Let me retrieve the full claim set and the prior-art references cited on the patent's face.

Obviousness Analysis — U.S. Patent No. 9,661,057 B2

0. Scope, and an important correction to the earlier sections

Correction / update to the prior "Patent summary" section. That section stated the verbatim claim set could not be retrieved and that claims were reconstructed only from the specification's Definitions section. In this session I retrieved the actual text of claims 1–3 (via the Justia full‑text mirror of the patent: https://patents.justia.com/patent/9661057#3). That is a direct contradiction of the earlier caveat, and the verbatim text controls. Claims 4 and following were still not retrieved — so any analysis of them below is flagged as incomplete.

What the "Prior Art" section of the Google Patents page actually contains. The page as served gives only:

• Prior‑art keywords: name data; destination name; terminal; destination; unit
• One reference named in the text: Japanese Laid‑Open Patent Publication No. 2012‑050063 (cited in the Background as the destination‑list/session‑establishment art)
• Priority document: JP Application No. 2012‑171192, filed Aug. 1, 2012
• "Family has litigation — First worldwide family litigation filed" (Darts‑IP family=50028107)

It does not render a "References Cited" list. Where I go beyond that single named reference below, I say so and cite the source. Treat the reference set as my identified art, not as the patent's face citations.

---

1. The claims at issue

Claim 1 (independent, verbatim):

A transmission management system comprising: processing circuitry; a destination name data managing unit, implemented by the processing circuitry, configured to manage a plurality of destination name data items which indicate a plurality of names for a single destination in communications between transmission terminals; a destination name data reading unit … configured to read at least one destination name data item from among the plurality of destination name data items …; and a destination name data transmitting unit … configured to transmit the at least one read destination name data item … to a transmission terminal which is configured to communicate with the destination, wherein: the destination name data managing unit is configured to associate first destination name data items with request source identification data for identifying request source terminals capable of communicating with the destination and manage the first destination name data items associated with the request source identification data items; the destination name data reading unit is configured to read a first destination name data item associated with a request source identification data for identifying a predetermined request source terminal …; and the destination name data transmitting unit is configured to transmit the first destination name data item … to the predetermined request source terminal.

Claim 2 (dependent): adds second destination name data items associated with reservation identification data items, read by reservation ID and transmitted to a terminal starting communications relevant to the reservation.

Claim 3 (dependent): adds the fallback — if a second (reservation‑specific) name is not managed, then read and transmit the first (request‑source‑specific) name.

(Claims 4+ unknown to me; the specification's remaining disclosed concepts are the third destination name data from the terminal management table (FIG. 12) and the corresponding terminal/system/recording‑medium claim sets.)

Key intrinsic admissions (these matter a great deal under §103, because they define the problem and concede the design space):

• "the easy‑to‑specify names of the destinations may vary depending on the communications" — the stated problem.
• "the destination name data is registered in response to receiving a request of registration of the destination name data in which a destination terminal … is designated."
• "the destination name data items may not be limited if the destination name data items indicate names of a destination … serial numbers, addresses, and phone numbers … project names, team names, and user names."
• "the plurality of first destination name data items are associated with the terminal IDs of the terminals 10 as the request source terminals and such data items associated with the terminal IDs are managed in the destination list management table (FIG. 10)."

---

2. Prior art identified

---

3. Claim 1 — obvious over PA‑1 + PA‑2 (+ PA‑3 / PA‑5)

Where each element is met.

• "transmission management system … manage a plurality of destination name data items which indicate a plurality of names for a single destination in communications between transmission terminals" — PA‑2 discloses exactly a plurality of names (the requester‑registered "Japan Tokyo Office, terminal C" and "Japan Tokyo Office, terminal AC") for one destination terminal having one terminal ID. PA‑1 supplies the surrounding transmission‑management‑system/session architecture.
• "associate first destination name data items with request source identification data for identifying request source terminals … and manage the first destination name data items associated with the request source identification data items" — PA‑2's destination list management table keys the registered destination name by requester terminal ID, verbatim (requester "10aa" vs. "10ab" ↔ different display names for the same destination). PA‑3 independently shows the same REQUEST SOURCE TERMINAL ID → DESTINATION TERMINAL ID table structure.
• "reading unit … read a first destination name data item associated with a request source identification data for identifying a predetermined request source terminal" — routine lookup keyed on the logged‑in terminal ID; PA‑1's management system already performs per‑terminal lookups (state management / change‑information handling) and PA‑2's system reads the requester's entry to build the destination list.
• "transmitting unit … transmit the first destination name data item … to the predetermined request source terminal" — PA‑1/PA‑2 both transmit a destination list back to the requesting terminal; sending the selected name is the same transmission with different payload content.

Motivation to combine. The motivation is not hypothetical — it is supplied by the '057's own specification and by PA‑2's own stated rationale: the "easy‑to‑specify name" of a destination differs by context (team name internally; company name externally). PA‑2 solves precisely that by letting the requester‑side register the name. Combining PA‑1's management system (which already transmits destination lists to requesters) with PA‑2's per‑requester name registry is nothing more than substituting PA‑2's name‑storage/name‑selection mechanism into PA‑1's known destination‑list delivery pipeline — the combination uses each reference for its established function. KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007) ("if a technique has been used to improve one device, and a person of ordinary skill in the art would recognize that it would improve similar devices in the same way, using the technique is obvious").

Secondary considerations absent/neutral. No teaching away (PA‑3's single global name is an older, simpler design, and the '057 itself characterizes it as the related art to be improved — a conceded deficiency, not a teaching away from the claimed solution). No unexpected result is asserted.

Bottom line on claim 1: Strong prima facie §103 case, and arguably even a §102(a)(2)/§102(e) anticipation-style case against PA‑2 alone on the "plurality of names for a single destination, keyed to request‑source terminal" limitation.

---

4. Claim 2 — obvious over {PA‑1 + PA‑2} further in view of reservation/scheduling art

Claim 2 merely re‑instantiates the same alias mechanism on a second key: instead of keying the alternative name to the request‑source terminal ID, key it to a reservation ID.

• The '057's own tables make the point for me: FIG. 10 (destination list management table) and FIG. 11B (reservation terminal management table) are structurally the same "name ↔ key" table; only the key changes (terminal ID vs. reservation ID). The specification says the second names are "associated with the reservation IDs."
• Meeting scheduling/reservation records keyed by a reservation identifier are notoriously old and ubiquitous (calendar/meeting‑scheduler art; and PA‑1's own system already manages per‑terminal communication state transitions around scheduled/actual sessions).
• Motivation: exactly the same as claim 1's — an "appropriate name" for the same destination across different meetings (the '057's own example: "Tokyo KK sales project team" for one meeting, "Tokyo" for another). Once the alias table is keyed by request‑source terminal, keying the same table by reservation is a predictable variation of a known data‑modeling technique. KSR, 550 U.S. at 417 (predictable variations of a known technique are obvious); In re KSR‑style "design choice" reasoning for adding a second indexing key to a lookup table.

Bottom line on claim 2: Strong prima facie §103 case; the "add a second foreign key / second lookup table" step is the paradigm of an obvious database design choice.

---

5. Claim 3 — the fallback hierarchy (the strongest, but still vulnerable, claim)

Claim 3 recites: if a reservation‑keyed name is not managed, then read the request‑source‑keyed (first) name and send it.

Why this is the least trivially obvious claim. It requires a priority/fallback algorithm, not just storage. It is the one place where a patentee could argue "the prior art stored alternatives; it did not teach a resolution order."

Why it is nevertheless likely obvious:

1. Fallback resolution ordering is a ubiquitous, well‑known computing technique — LDAP/AD attribute fallback (displayName → cn → sAMAccountName), DNS resolver ordering, CSS cascade, default‑value chains. Adding a "if absent, use the other table" branch to a two‑table lookup is a predictable, conventional programming step.
2. The intrinsic record motivates it. The specification states the purpose is "even when the second destination name data item associated with the reservation ID is not managed, the management system 50 may read the first destination name data item." That is the stated design goal — availability/robustness of the display name — and the claimed ordering (i.e., prefer the context‑specific name, fall back to the user‑specific name) is the most natural hierarchy: most‑specific‑to‑least‑specific. Choosing that order over the reverse is at most an arbitrary/design‑choice distinction with no asserted unexpected result.
3. KSR teaches that "a court must ask whether the improvement is more than the predictable use of prior art elements according to their established functions." Id. at 417. A null‑check branch on a table read is the definition of established function.

Defensive posture if I were the patentee. I would argue (a) claim 3's ordering encodes a non‑trivial policy decision about which of two semantically different names a user should see, and (b) the prior art does not disclose the specific pair of keys (reservation ID → request‑source terminal ID). Those are real but narrow arguments; they are claim‑scope arguments, not patentability arguments, and they are rebutted by the motivation analysis above.

---

6. Motivation‑to‑combine summary (and the "single reference" alternative)

Why a PHOSITA would combine PA‑1 + PA‑2 (+ PA‑3):

1. Same field, same architecture, same problem. All are Ricoh transmission/videoconference‑management systems with a management server, a destination list management table, a terminal management table, and terminals that log in and request sessions. PA‑1 is the reference the '057 itself identifies as the starting point.
2. PA‑2's improvement is the very improvement the '057 seeks. PA‑2 already lets "a desired name … be registered as a destination name … for each requester terminal," expressly to make the name easy for that requester to identify. A PHOSITA facing the '057's stated problem ("easy‑to‑specify names … vary depending on the communications") would immediately look to the same assignee's per‑requester naming mechanism (and to the general address‑book/alias practice of PA‑5).
3. PA‑3 teaches the complementary half — the system‑wide "destination name" stored per terminal ID in the terminal management table plus the request‑source→destination list table — supplying the third‑level name and the table architecture.
4. Predictable combination, each element used for its established function — the KSR "predictable use of prior art elements according to their established functions" formulation, and the KSR "improve similar devices in the same way" rationale. There is no change in the references' respective operating principles.
5. Common‑sense / known‑technique reinforcement (PA‑5): "multiple aliases for one entity, resolved by context or lookup order" is a bedrock database/directory design pattern of the era. Under KSR, a PHOSITA's common sense and common knowledge may supply a missing limitation, and a "motivation to combine need not be found in the references themselves."

Single‑reference route. For claim 1, PA‑2 alone plausibly discloses nearly every limitation (a names‑per‑requester registry in a transmission management system, read and transmitted to the requesting terminal), so a §102/§103 single‑reference challenge is available. For claims 2 and 3, PA‑2 + a reservation/scheduling reference (or PA‑1, which manages session/state around scheduled communications) is the cleaner combination.

---

7. Rebuttals a PHOSITA/patentee could raise, and my assessment

---

8. Mandatory caveats and uncertainty disclosures

1. Prior‑art qualification dates were not fully verified, and two of my references have real §102(b)(2) exposure:
   • PA‑2 (US 2013/0173800 A1) published on 2013‑07‑04 — after the '057's effective filing date of 2012‑08‑01. It can therefore only be prior art via AIA §102(a)(2) as of its own earlier effective filing date, which I did not confirm. If PA‑2 and the '057 share an owner (both are Ricoh), §102(b)(2)(C) common ownership could disqualify PA‑2 as 102(a)(2) art. Verify PA‑2's JP priority date and its assignment/ownership chain before relying on it.
   • PA‑3 (US 8,885,008 B2) issued 2014‑11‑11, also after the '057's effective filing date; it qualifies only as 102(a)(2)/pre‑AIA 102(e) art as of its own filing date (not confirmed). Worse, Takahiro Asai is a named inventor on both US 8,885,008 and the '057, which raises §102(b)(2)(A) ("subject matter … obtained directly or indirectly from the inventor or a joint inventor") issues. Flag before use.
   • PA‑1 (JP 2012‑050063) published 2012‑03‑08, before 2012‑08‑01 → clean §102(a)(1)/pre‑AIA §102(b) art. This is the one reference I am confident is qualifying.
2. Claim text: claims 1–3 are verbatim from Justia (https://patents.justia.com/patent/9661057#3); claims 4 and any further dependents were not retrieved. If the patent contains a claim specifically reciting the third destination name data / terminal management table fallback (as the specification strongly implies), my analysis of that claim is not provided and would need to be added.
3. "Prior Art section of this page": the Google Patents page as served exposes only the prior‑art keywords and JP 2012‑050063, and does not render a "References Cited" list. PA‑2, PA‑3, PA‑4 are my identified art, not the patent's face citations. If the actual face citations include references I did not surface, the combination set should be re‑run.
4. PA‑5 is invoked as common knowledge under KSR, not as a specific exhibit; if the work product requires documentary support, substitute a concrete pre‑2012 directory/address‑book reference (e.g., an LDAP RFC attribute specification, or a pre‑2012 videoconferencing admin guide) rather than resting on "common sense" alone.
5. No post‑grant challenge was located. Consistent with the previously generated Litigation section, no IPR/PGR or district‑court case asserting the '057 patent itself was found; the flagged Darts‑IP family litigation (family=50028107) was not resolvable to a specific case for this patent in this session.

---

9. Bottom line

• Claim 1 is highly vulnerable under §103 over JP 2012‑050063 (PA‑1) in view of US 2013/0173800 A1 (PA‑2), with US 8,885,008 B2 (PA‑3) as a supplementary teaching of the terminal/destination‑list table architecture, and general alias/directory practice (PA‑5) as common knowledge. PA‑2 alone is a plausible single‑reference challenge. Motivation is expressly supplied by the '057's own specification and by PA‑2's own stated purpose.
• Claim 2 is highly vulnerable — it is the same alias mechanism re‑keyed from request‑source terminal ID to reservation ID, a predictable data‑modeling variation over the same combination.
• Claim 3 is the most defensible claim (a two‑level fallback ordering), but is still likely obvious as an established "default‑on‑null" technique preferring context‑specific names over user‑specific names, with the motivation to provide a name even when the reservation is unregistered stated in the specification itself.
• Highest‑value next steps: (a) verify PA‑2's and PA‑3's effective filing dates and ownership to confirm they qualify as prior art given the 2012‑08‑01 priority date; (b) obtain the face "References Cited" list and the full claim set (claims 4+) for a complete analysis.