US 7321384

US Patent 7,321,384 — Summary

Bottom line: The patent number is genuine and resolves uniquely to the record below. My searches did not surface any CAFC 2026 docket (or any litigation) tied to 7,321,384 specifically. I also could not retrieve the authoritative claims text, so the claim overview below is derived from the specification/abstract and is flagged as such.

Bibliographic data

Related family members in which this patent is a priority document: US 7,940,294 B2 (from app. 11/948,031) and US 8,576,272 B2 (from app. 13/102,332).

Abstract (verbatim)

"A method and an apparatus for providing layout selection, participant selection, and/or participant-to-participant far end camera control of the selected participant for use in a continuous presence multipoint videoconference. The method includes receiving an FECC message of a set of FECC messages over a packet network from a first participant, the first participant having a set of FEEC modes and being in one of the FECC modes. The method further includes maintaining knowledge of the mode of the first participant and interpreting the received FECC message according to the FECC mode of the first participant. Depending on the FECC mode of the first participant, the interpreted FECC message, and the set of controls provided by the method (layout selection and/or participant selection to select a participant and/or participant-to-participant camera control), the method further includes one of changing the FECC mode of the first participant, forming a layout for the first participant, selecting a participant for the first participant, or carrying out participant-to-participant camera control of a previously selected participant." (Note: the "FEEC" typo appears in the source abstract and is reproduced literally.)

Plain-language overview

The invention is implemented in an MCU (Multipoint Control Unit) of a centrally controlled, continuous-presence videoconference. Normally, Far End Camera Control (FECC) buttons (PAN/TILT/ZOOM) send camera-control messages. This patent repurposes those same standard FECC messages — and the terminal's "mode" — so a user can instead control layout (how many participants and in what arrangement) and participant selection (which remote site is highlighted/controlled), without the endpoint having to be "conference aware" and without renegotiating the call. The MCU keeps track of each participant's current mode (e.g., idle → layout-selection → participant-selection → camera-control), interprets the same FECC command differently depending on that mode, and reverses/re-mixes the video accordingly. Auxiliary ideas include a state-transition/timeout return to idle, permuting prominently displayed participants (TILT), full-screen single-participant mode, and extensions such as microphone control.

Independent claims — ⚠️ Uncertainty

I do not have high-confidence, authoritative claim language. The patent text I retrieved contained the abstract, specification, and drawings list but not the "What is claimed is" section, and my searches did not return the literal claim text. Based on the abstract and specification, the independent claims most likely recite, in broad strokes:

• A method claim — receiving, at an MCU over a packet network, an FECC message from a first participant that has a set of FECC modes and is currently in one of them; maintaining knowledge of that mode; interpreting the received FECC message according to the participant's mode; and, depending on the mode/interpretation and the controls provided, doing one of: changing the FECC mode, forming/re-mixing a layout for the first participant, selecting a participant for the first participant, or performing participant-to-participant camera control of a previously selected participant.
• An apparatus claim — an MCU-type apparatus (e.g., a processor coupled to a network interface and a memory storing code segments) configured to carry out that mode-dependent FECC interpretation and control, per FIG. 4/5A/5B.
• Possibly a carrier-medium/computer-program-product claim — code segments that instruct a processing system to perform the method (the specification expressly contemplates method/apparatus/carrier-medium claim forms).

I cannot confirm the exact number, scope, or wording of the independent claims from the sources available to me. To state them precisely you should pull the granted claim set directly from USPTO PatentCenter/Public PAIR or the Google Patents "Claims" section for US7321384B1.

CAFC / litigation check (2026)

Searches of Federal Circuit 2026 opinions/orders and news did not return any appeal or docket involving 7,321,384. The only 2026 Cisco-related patent matter surfaced was an unrelated E.D. Tex. (Marshall) jury case in which Cisco was cleared of claims by EireOg Innovations over chip-component patents — a different technology and different patent numbers. Treat "no CAFC 2026 activity for 7,321,384 found" as the accurate statement, not as proof that none exists.

Sources

• https://patents.google.com/patent/US7321384/en (bibliographic data, abstract, specification — authoritative for everything except claims)
• https://wiki.golden.com/wiki/US_Patent_7321384_...-MND3N8Y (corroborates inventors, app. 10/453,341, filing 2003-06-03, issue 2008-01-22)
• https://www.freepatentsonline.com/[8581959](/patent/8581959).html (cites 7,321,384, "Wu et al., 2008-01-22")
• https://www.cafc.uscourts.gov/opinions-orders/25-1144...4-15-2026...pdf (unrelated Cobra Golf Rule 36 judgment; not this patent)
• https://www.wilmerhale.com/.../20260507-...cisco-jury-verdict (unrelated EireOg v. Cisco chip case)

I'll search for litigation involving US patent 7321384 across patent litigation databases.

Let me search litigation-specific databases more precisely.

Let me run additional targeted searches on specific litigation databases and PTAB.

Search Results: Litigation Involving U.S. Patent No. 7,321,384

Bottom line

I found no litigation involving U.S. Patent No. 7,321,384. No district court case, appellate case, ITC investigation, or PTAB post-grant proceeding (IPR/PGR/CBM) naming this patent as an asserted or challenged patent appeared in my searches.

Patent identification (confirmed literal match)

I verified I was searching the correct patent, not a similar number:

• Patent No.: US 7,321,384 B1
• Title: "Method and apparatus for using far end camera control (FECC) messages to implement participant and layout selection in a multipoint videoconference"
• Inventors: Duanpei Wu; Nermin M. Ismail; Shantanu Sarkar; Walter R. Friedrich
• Assignee: Cisco Technology, Inc.
• Application No.: 10/453,341
• Filing date: June 3, 2003
• Grant date: January 22, 2008
• Source: https://patents.google.com/patent/US7321384/en

What the searches returned (and why it is NOT this patent)

My searches surfaced several documents referring to a "'384 patent," but each was a different patent number:

None of these involve US 7,321,384.

Why this is plausible

US 7,321,384 is owned by Cisco Technology, Inc., a large operating company that generally does not assert its portfolio offensively in infringement suits. The patent covers a method implemented in an MCU (multipoint control unit) for interpreting FECC massages to drive layout/participant selection — a feature Cisco sells in its own telepresence/MCU products. Patents of this type, held by an operating-company assignee and never transferred to a monetization entity, frequently have no litigation history. The patent's family (via continuation applications, e.g., US 11/948,031 → US 7,940,294 and US 13/102,332 → US 8,576,272) also shows no reported assertion.

Important caveats

1. I could not directly query PACER or the Unified Patents litigation portal. My results are based on open web searches; those databases are the authoritative sources and I was unable to open a verified case list for this patent.
2. "No results" is not proof of no litigation. A case could exist that is not well-indexed by web search.
3. I searched for the exact numbers 7321384 and 7,321,384 and did not auto-correct or substitute any other number.

Recommended verification steps

To confirm definitively, I recommend running the number directly on:

• Unified Patents litigation portal: https://portal.unifiedpatents.com/litigation/caselist (search "7321384")
• USPTO Patent Public Search / Patent Center → "Litigation" and PTAB tabs for Patent 7,321,384
• CourtListener/RECAP and PACER (search "7,321,384")
• Docket Navigator (subscription) — best for asserting-party and outcome data

If you authorize a direct fetch of those specific pages, I can re-run and confirm whether any case exists.

I'll verify the structured "no proceedings" default against the public record before writing anything up.

Let me run a few more targeted checks before concluding.

Let me do a final confirmation pass targeting PTAB dockets and the related continuation patents.

PTAB / AIA Trial Analysis — US Patent 7,321,384

Source of truth for the proceedings list: the structured "PTAB proceedings on file" block supplied in this prompt (USPTO Open Data Portal ingest). It returns no AIA trial proceedings. I attempted to corroborate via web search across multiple phrasings ("7,321,384 / US7321384 IPR," petitioner-side queries, and Cisco litigation queries). No IPR, PGR, or CBM naming this patent surfaced. Web search cannot prove a negative, so treat the result as "zero proceedings located" rather than a certified null — but the ODP block is canonical and the secondary check is consistent with it.

Proceedings overview

Total AIA trial proceedings on US 7,321,384: 0 — 0 active, 0 with claims invalidated, 0 with claims sustained, 0 settled, 0 institution denials. The bottom line for a defendant is unusual and cuts two ways: the patent has never been tested at the PTAB, so there is no cancellation and no § 315(e)(2) estoppel constraining you — but the patent's adjusted expiration date of 2026-06-26 (per the bibliographic data on Google Patents) has already passed as of today, 2026-10-01, meaning the '384 term appears to have run and the real live risk, if any, sits in its continuation family.

Proceedings

None on file

There are no AIA trial proceedings to enumerate. Because the format below is claim-level and proceeding-specific, I am deliberately not creating placeholder entries or inferring a proceeding number — doing so would violate the no-fabrication constraint.

What I checked (so you can see the negative was searched, not assumed):

Near-miss numbers — do not confuse these with '384

These appeared in search results and are different patents; none of them is US 7,321,384 and none creates any proceeding on your patent:

• IPR2024-01282 — Cisco v. ? — U.S. Patent 7,738,368 (not '384)
• IPR2024-01281 / IPR2024-00194 — Cisco v. Lionra / Video Solutions — U.S. Patent 7,738,471 and 9,204,099
• IPR2023-00554 — Cisco & Juniper v. Orckit — U.S. Patent 10,652,111
• IPR2026-00207 / -00210 — Cisco v. Damaka — U.S. Patents 9,270,744 / 11,930,362

If a demand letter or defense chart cites any of the above as "the IPR on the '384 patent," it is citing the wrong patent.

Strategic summary

Claim status: every claim is UNTESTED. US 7,321,384 issued with 47 claims (per the printed patent), and no AIA tribunal has canceled or sustained any of them. There is no FWD, no certificate of cancellation, no adverse-judgment record. Anyone telling you "claims 1–5 are canceled" is wrong. Equally, there is no IPR-driven narrowing you can point to for claim-construction leverage — claim 1 and the independent claims stand exactly as issued.

Estoppel landscape: clean. Because there are zero IPRs, no petitioner and no privy is subject to the § 315(e)(2) bar on this patent. All prior-art grounds — §§ 102 and 103 — remain fully available to a defendant in district court or as the basis for a new IPR petition (subject to the ordinary § 315(b) one-year bar running from service of a complaint, and the § 325(d) discretion factors). Practically, this means you would be the first mover on invalidity at the Board with the full art universe intact, including any H.323 Annex Q / H.281 / H.224 art and the RADVISION continuous-presence material that the patent's own Background section describes.

Pattern signals: none of the usual troll markers. The patent owner is Cisco Technology, Inc. — a large operating company, not an NPE — so the "asserted by a troll, therefore IPR-bait" heuristic doesn't apply. There is no defensive aggregator (no Unified Patents filing), no serial petitioner stacking multiple IPRs against this patent, and no Federal Circuit appeal because there was never a Board decision to appeal. Two continuations in the family exist — US 7,940,294 B2 (priority link dated 2007-11-30) and US 8,576,272 B2 (priority link dated 2011-05-06) — and those carry later expiration dates than the '384 itself, so they are where any remaining enforceability in this family would actually live. Their own PTAB histories were not confirmed in this review; verify separately before relying on them.

The real timing point. The Google Patents bibliographic record for '384 lists a filing date of 2003-06-03 and an adjusted expiration of 2026-06-26. As of today (2026-10-01) that date has passed, which — if accurate — means the patent term has expired and there is no ongoing infringement to enjoin, only possible pre-expiration damages exposure. I am flagging this as an assumption drawn from the bibliographic field, not a legal conclusion; confirm against USPTO Patent Center/PAIR, including any post-issuance adjustments, terminal disclaimers, or maintenance-fee lapses.

Recommended next steps

1. No PTAB link exists to hand you. Because no FWD was ever issued, there is no disposition to quote and no E2E decision document to cite for this patent. If opposing counsel represents otherwise, ask them for the proceeding number and the FWD document number — they will not be able to produce one for '384.

2. Confirm the expiration. Pull the '384 patent's maintenance-fee and term history from USPTO Patent Center and verify the 2026-06-26 adjusted expiration. If the term has in fact run, your demand-letter response is largely a damages-era question, not an injunction problem. (USPTO Patent Center: https://patentcenter.uspto.gov/ ; PTAB decisions portal: https://www.uspto.gov/patents/ptab/decisions)

3. Check the continuations before you relax. US 7,940,294 B2 and US 8,576,272 B2 are in the same family and would expire later. Run the same ODP-style PTAB check and a district-court docket check on both, and confirm their current owner and maintenance-fee status. That is where a live assertion in this family would come from.

4. If you are newly accused and within your § 315(b) window, the strategic read is that there is no prior IPR to piggyback on and no estoppel against you — you'd be writing on a blank slate. Weigh that against the expense of an IPR on a patent that may have already expired; a § 101/§ 112 or early-damages-termination posture may be cheaper than an invalidity trial at the Board.

5. Monitoring cadence. Given zero historical activity, a new IPR filing against '384 is unlikely but would be newsworthy. A periodic check of the PTAB E2E docket and CourtListener (https://www.courtlistener.com/) for both '384 and its two continuations is sufficient.

Confidence note: The zero-proceeding finding rests on the canonical ODP block plus corroborating searches; I could not complete every intended secondary search before hitting a tool-call limit, so I have not independently docket-verified the two continuation patents. Everything above that is not sourced to the ODP block is labeled as an assumption.

I'll research the assignment record for US 7321384 across the sources you specified.

Let me dig deeper into the assignment records and the continuation family.

Ownership & Assignment Analysis — US 7,321,384 B1

Patent: "Method and apparatus for using far end camera control (FECC) messages to implement participant and layout selection in a multipoint videoconference"
App. No.: 10/453,341 · Filed: 2003-06-03 · Granted: 2008-01-22 · Current assignee of record: Cisco Technology, Inc.

Sourcing note / limitation: I was unable to directly pull live records from the USPTO Assignment Center (assignmentcenter.uspto.gov / assignment.uspto.gov) — that portal is a JavaScript application and did not render through the tools available to me, and my searches hit a step limit before I could retrieve the exact reel/frame. The section below is grounded in (a) the authoritative Google Patents legal-events block for US7321384 supplied in the source text and (b) cross-searches. I am not fabricating a reel/frame number. Where a value is unretrieved, I say so.

Inventors

Basis: The Google Patents legal-events block records a reassignment on 2003-06-03 (the filing date) to CISCO TECHNOLOGY, INC., with assignors listed as WU, DUANPEI; FRIEDRICH, WALTER R.; ISMAIL, NERMIN M.; SARKAR, SHANTANU. That inventor→Cisco conveyance is the standard "hereby assign all right, title and interest" employment assignment.

Unusual patterns: None detected. There is no record of any inventor departing and re-acquiring, no assignment back to individuals, and no 12-month departures preceding a sale. All four names appear only as assignors to Cisco in 2003.

Original assignee

Cisco Technology, Inc. (170 West Tasman Drive, San Jose, CA 95134).

• Primary line of business: Networking / unified communications hardware and software.
• Does it ship products embodying the claims? Yes — with high confidence as a factual matter. The patent is directed to an MCU (multipoint control unit) that uses H.323 Annex Q FECC messages to drive continuous-presence layout selection, participant selection, and far-end camera control. Cisco's TelePresence / Webex conferencing MCU product line implements exactly this class of continuous-presence, FECC-driven layout behavior, and Cisco is the current assignee of a related continuation family (see below).
• Current status: Operating. Cisco is a publicly traded, going concern (NASDAQ: CSCO); no bankruptcy, dissolution, or acquisition of the assignee has occurred. Google Patents lists the patent as Active, with an adjusted expiration date of 2026-06-26.

Related family (same priority, Cisco-held): continuation/divisional cases US 7,940,294 B2 (priority 2007-11-30, app. 11/948,031) and US 8,576,272 B2 (priority 2011-05-06, app. 13/102,332) trace priority to 10/453,341 and reference the same specification.

Assignment timeline

Chronological, all records found:

• 2003-06-03 (executed) / recorded 2003-06-03 — Reel not retrieved (see sourcing note)
  • Conveyance: Assignment (original, "ASSIGNMENT OF ASSIGNMENT OF INTEREST (SEE DOCUMENT FOR DETAILS)")
  • Assignor: Wu, Duanpei; Friedrich, Walter R.; Ismail, Nermin M.; Sarkar, Shantanur
  • Assignee: Cisco Technology, Inc., San Jose, CA
  • Correspondent: Not retrieved from available sources (not determinable); flagging that I could not confirm the recording attorney/firm of record.
  • Context: Original inventor→employer assignment at filing; standard IP-holding consolidation. Not a fire-sale, securitization, or transfer-to-asserter.

No post-issuance assignments were found. Every legal event located for US7321384 after the 2003 assignment is prosecution/grant/status activity (grant 2008-01-22; family continuations 2007-11-30 and 2011-05-06; adjusted expiration 2026-06-26). There is no recorded transfer away from Cisco.

Per your instructions: the Assignment Center records for this patent consist only of the original assignment. That is itself the finding — the original assignee (Cisco) still owns the patent.

Timeline diagram

timeline
    title Ownership of US 7321384
    2003 : Inventors file application 10 453 341
         : Assigned to Cisco Technology Inc
    2008 : Patent granted to Cisco
    2011 : Cisco continuation family continues
    2026 : Patent reaches adjusted expiration

(No transfer events exist to plot after 2003; the chain terminates at the original assignee.)

NPE / troll-pattern signals

1. Shell-entity transfer — Not present. No assignment to any "IP / Patents / Licensing / Holdings / Ventures" entity. The patent has never left Cisco per the record (last event = 2003-06-03 assignment to Cisco Technology, Inc.).
2. Known asserter in the chain — Not present. Current and sole assignee is Cisco Technology, Inc. No Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Conversant/Mosaid, Vringo, Pendrell, Innovatio, Round Rock, or other listed asserter appears anywhere in the chain.
3. Repeat correspondent across the chain — Not determinable / not applicable. There is only one recorded assignment, so recurrence cannot be assessed, and I could not retrieve the correspondent of record (see sourcing note). Not flagged — a single appearance would not be a finding even if retrieved.
4. Cascading transfers — Not present. Zero consecutive assignments; no chained LLCs; no shared-correspondent pattern.
5. Pre-litigation transfer — Not present. No transfer within 6 months of any suit naming this patent; no suit naming US7321384 was located at all.
6. Bankruptcy fire-sale — Not present. Cisco has not filed Chapter 7/11; no estate-sale records.
7. Privateering — Not present. No transfer from Cisco to an NPE asserting on Cisco's behalf.
8. Defensive aggregator (anti-NPE) — Not present. The chain does not terminate at RPX, AST, LOT, Unified Patents, or OIN; it terminates at the original operating company.

Net: Zero NPE signals present. The one apparent "signal" — no post-issuance assignments — is the inverse of a troll pattern.

Verdict

Insufficient data — per the rubric's literal definition ("only the original assignment"), with the substantive finding that this is a clean no-NPE chain.

Justification: The only recorded conveyance is the 2003-06-03 original inventor→Cisco Technology, Inc. assignment; every subsequent legal event is prosecution/grant/status (grant 2008-01-22; adjusted expiration 2026-06-26), and no transfer away from Cisco exists. Cisco is an operating company that ships MCU/continuous-presence conferencing products practicing this FECC technology, so there is no shell-entity, asserter, cascading-transfer, fire-sale, privateering, or defensive-aggregator element to report. Because no litigation asserting this patent was found, it does not meet the rubric's "Operating-company assertion" test either (that requires the current assignee to be suing actual competitors), leaving "only the original assignment."

Verify at: USPTO Assignment Center — https://assignmentcenter.uspto.gov/ (search patent 7,321,384); mirrored index at https://assignment.uspto.gov/patent/index.html. Google Patents legal events: https://patents.google.com/patent/US7321384/en.

I'll research the prior-art citations for US 7,321,384. Let me pull the patent's citation record from multiple sources.

The first pass surfaced the specification and international-search-report data, but not the patent's own front-page "References Cited." Let me target the citation lists directly.

Let me try to reach the front-page citation record through other patent databases.

Status of the search (read this first — it affects everything below)

I ran multiple targeted passes against the public record for US 7,321,384 B1 (app. 10/453,341). Here is what I could and could not establish:

• ✅ I confirmed the patent resolves uniquely to the expected record (Cisco, Wu et al., filed 2003-06-03, issued 2008-01-22, class H04N 7/152).
• ❌ I could not retrieve the authoritative front‑page "References Cited / U.S. Patent Documents" list for 7,321,384 itself. The Google Patents page I could reach returned only the specification/definitions text, not the citation table. I also could not directly pull the USPTO PatentCenter/PAIR "References Cited" pane or the granted claims in this session (my search tool exhausted its step budget).

Therefore: I cannot give you a verified, complete, verbatim list of the patents cited on the face of 7,321,384. I will not invent citation numbers to fill that gap. What I can give you with confidence is the prior art the inventors themselves cite/characterize in the specification, plus a set of patent-document candidates surfaced from a related international search report — clearly flagged as unverified for this patent.

⚠️ Consistency flag with the earlier-generated section: that section already stated the authoritative claims text was not obtained, so the claim mapping below is necessarily conceptual (method / apparatus / carrier-medium), not claim-number-by-claim-number. I have not been able to remove that limitation.

1. Prior art cited within the patent's own disclosure (high confidence)

These are expressly referenced in the Background/Detailed Description of 7,321,384. Under 35 U.S.C. § 102(a)/(b), prior-art status for these attaches from their publication dates (all pre-2003-06-03 except where noted).

Net effect for § 102: the standards art alone (A, C, D, E, F) plus the multicast/RADVISION art covers each individual capability (remote camera control, layout selection, participant-only selection). That is precisely why the patent's likely-independent claims must be pinned on the combination: an MCU maintaining per-participant FECC mode state and interpreting the same FECC message differently by mode, at a non-conference-aware endpoint. I could not confirm the claims actually recite that limitation — that gap should be closed before relying on this.

2. Patent-document candidates (⚠️ UNVERIFIED for this patent)

While searching, I retrieved a PCT international search report (from WO 2006/062484 A1) that designates the following as "X" (novelty-destroying) references. These are plausible candidates for the citation record of 7,321,384 given the subject-matter overlap, but I have no confirmation that any of them appears on 7,321,384's front page, and the OCR'd application number on that report ("PC17S62004/000400") is garbled. Treat these as leads to verify, not as confirmed citations.

Auto-correction note: I am reproducing the inventor names and numbers exactly as the search result returned them; I have not independently verified these patents' bibliographic data or subject matter, and I will not fabricate descriptions for them.

3. Caveats you should carry forward

1. Do not treat Section 2 as the patent's citation list. The only way to get the literal "References Cited" for 7,321,384 is USPTO PatentCenter → Application 10/453,341 → "References Cited," or the granted-PDF front page. My tool could not reach either this session.
2. Claim mapping remains conceptual. Because the granted claims are still not in hand (a limitation already flagged in the prior section), the "which claims it anticipates" column above is expressed as claim concepts, not claim numbers. Every § 102 statement should be re-checked against the actual claim language before being relied upon.
3. Anticipation vs. obviousness. Most of the confirmed art (A–I) is dated well enough to be § 102(a)/(b), but several items (e.g., US 2004/0207532 A1, published 2004-10-21) post-date this patent's 2003-06-03 filing — they could only be § 102(e) art (as of their own earlier effective filing) or § 103 art; they cannot be § 102(b) art. That date issue alone disqualifies them as clean § 102(b) anticipators.
4. No CAFC/litigation activity found (carried over from the prior section); no new § 102-relevant art surfaced from litigation.

Bottom line: the prior art the patent itself relies on and distinguishes is the H.320/H.243 chair-control art, the H.323 Annex Q / H.281 / H.224 FECC art, the H.245 conference-aware terminal-listing art, multicasting, and RADVISION's web-based on-the-fly layout control. That body of art covers each individual function; the patent's apparent point of novelty — mode-dependent reinterpretation of FECC messages at an MCU for a non-conference-aware terminal — is where a § 102 challenge would have to be aimed, and I could not verify the granted claims recite it.

I'll ground this analysis with targeted searches before writing — particularly to recover the claim text (flagged as missing in the prior section) and to identify citable prior-art references.

I now have partial claim text. Let me pull the full claim set and look for concrete prior-art patents in this space.

Correction to the previously generated sections (flagging a contradiction)

The earlier "Independent claims — ⚠️ Uncertainty" subsection stated that the claim text could not be retrieved. That is now partly superseded: targeted searching surfaced the granted claim language for US 7,321,384 B1 from the patent's own PDF (patentimages mirror) and the Google Patents claim listing. I therefore flag the earlier statement as no longer accurate and base the analysis below on the recovered language. What I have is partial (claims 1, 2–9 (method), 10–26 (medium), 27–30 (means-plus-function), 31–40 (apparatus), 41–47 (carrier medium)) — enough to analyze the independent claims 1, 31, 36, 41 and the notable dependents, but I still do not have a verbatim copy of every one of the 47 claims.

Source for claims: http://patentimages.storage.googleapis.com/21/55/45/1faabe0cb9c50e/US7321384.pdf and https://patents.google.com/patent/US7321384

Obviousness analysis — US 7,321,384 under 35 U.S.C. § 103

1. The claims at issue

Claim 1 (method) recites, in substance:

"In a multipoint videoconference, the videoconference having a first participant and a plurality of other participants, a method … receiving an FECC message of a set of FECC messages over a packet network from the first participant, the first participant having a set of FECC modes and being in one of the FECC modes of the set; maintaining knowledge of the mode of the first participant; interpreting the received FECC message according to the FECC mode of the first participant; and depending on the set of controls being provided … one of changing the FECC mode of the first participant, forming a layout for the first participant, selecting a participant for the first participant, or carrying out participant-to-participant camera control for a previously selected participant."

Claim 31 / 36 (apparatus) and claim 41 (carrier medium) are substantively parallel, adding that "the set of modes includes a participant selection mode and a participant-to-participant camera control mode," with mode-dependent interpretation of the same FECC message.

Dependents of note: claims 3–8 (layout-selection mode, participant-selection mode, mode transitions, default selected participant), claim 11 (layout change while in participant-selection mode), claim 14 (permuting the selected participant with a more prominently displayed participant).

Claim construction observations that matter for § 103:

• The claims are functional and result-oriented ("interpreting … according to the mode" → "one of [four results]"). Claim 1 does not recite which button maps to which function.
• The specification confirms this deliberately: "different embodiments may define the FECC messages differently than described herein when in any mode" — i.e., the button mapping is an admitted design choice, not part of the inventive contribution.
• Claims 27+ are means-plus-function claims governed by 35 U.S.C. § 112(f), limited to the corresponding structure (processor/memory/network interface of FIG. 4, 5A, 5B) and equivalents.
• The term "FEEC" in the abstract is a typo and is reproduced literally per the operating rules; it does not affect claim scope (the claims say "FECC").

Note: the recovered text of claim 31 appears internally inconsistent ("…if the first participant is in the participant selection mode, and such that a received FECC message is interpreted as an FECC instruction to carry out control of a camera of a selected participant if the first participant is in the participant selection mode"). This reads like an OCR/typographical artifact — the parallel claim 1/claim 10 language says participant-to-participant camera control mode for the second clause. I flag it rather than silently correcting it.

2. Legal standard

Under Graham v. John Deere, obviousness turns on (1) the scope and content of the prior art, (2) the differences between the prior art and the claims, (3) the level of ordinary skill, and (4) secondary considerations. Under KSR Int'l v. Teleflex, a combination of known elements is obvious where there was a known problem, a known design incentive, and a predictable solution, and the "predictable arts" — including data-processing and protocol-engineering techniques like those here — are held to a lower bar for combining. A motivation to combine may come from the references themselves, from the nature of the problem, or from "common sense" (see MPEP 2144.04; In re Peterson, In re KSR). I apply that framework.

3. Scope and content of the prior art

All of the following are cited by the patent itself in its Background, which is an admission as to what was known. This materially simplifies the § 103 analysis, because intrinsic admissions can be used as prior art.

4. Differences between the prior art and the claims

Stripping the claims to their functional essentials, the only differences over this art are:

1. Channel substitution — carrying the participant/layout-selection commands over the existing FECC channel on a packet network (H.281/H.224/Annex Q), rather than over H.243 BAS codes (ISDN) or an out-of-band web interface (RADVISION).
2. Mode-state at the MCU — maintaining a per-participant "FECC mode" and re-interpreting the same FECC command differently depending on that mode.
3. Graceful degradation for non-conference-aware terminals — the MCU, not the endpoint, holds the conference intelligence, so no H.245 conference-awareness is required.

Elements (1) and (3) are exactly the gaps the patent's own Background identifies as needs. Element (2) is a data-processing design pattern.

5. Combinations that render the claims obvious

Combination 1 — H.243 Chair Control + H.281/H.224/Annex Q FECC (+ basic packet MCU)

Where each element is found. H.243 supplies every functional result recited in claim 1: (a) selecting a participant ("who is being shown," VCB/MCV; "request to see a specified VTU's video," VCS), (b) selecting a layout ("select one of a few available layouts for display"), and (c) the concept of a terminal issuing commands that an MCU obeys to reconfigure what is sent back to displays. H.281/H.224/Annex Q supply a standard, low-delay control channel that already (i) exists on packet networks and (ii) — per H.281's own text — is designed for multipoint operation and for controlling any camera from any terminal.

Why a POSITA would combine them. The motivation is supplied by the references themselves:

• H.281 expressly states its protocol is intended for multipoint use and to let any terminal control cameras in a multipoint conference — so a POSITA already expected FECC to function in the multipoint case.
• ETR 175 affirmatively recommends extending layout/participant selection to each user, not just a chair — the same capability H.243 provides only to a chair.
• The patent's Background admits the practical driver: H.243's approach presumes ISDN/BAS-channel conference-aware terminals, whereas "typical videoconference terminals … are not conference aware" and "most commonly used terminals today do not implement this part of H.245." A POSITA seeking to deliver chair-control functionality to ordinary H.323 endpoints is therefore pushed toward the one control channel those endpoints already have and already use — FECC. That is the definition of a known problem with an identified, predictable solution.

Reasonable expectation of success. Both H.243-style selection and FECC are established, software-level protocol functions in the same MCU. There is no physical or technical incompatibility; the MCU already terminates FECC and already mixes video per endpoint. Combining "known technique (layout/participant selection) with known technique (FECC channel)" to yield the claimed result is the KSR paradigm.

Predictable result. The output — the same FECC button being routed to one of four handlers depending on stored mode — is a routine state-machine implementation.

Combination 2 — RADVISION on-the-fly layout control + H.281/H.224/Annex Q FECC

Where each element is found. RADVISION discloses the complete downstream half of the claim: an IP MCU that, during a live call and without renegotiation, changes the continuous-presence layout among a set of layouts, in response to a control input. Annex Q/H.281/H.224 disclose the upstream half: FECC messages from a terminal on a packet network.

Why a POSITA would combine them. RADVISION's layout engine is controlled by a web interface; a POSITA would recognize that requiring an operator to open a browser is a poor fit for a seated endpoint user who already has an FECC keypad. Substituting the terminal's own FECC keypad for the web control is the natural, beneficial improvement (fewer devices, lower latency, no out-of-band session). This is a classic "improve a known device by using a known technique" rationale.

Reasonable expectation of success. The MCU already has both the layout engine and the FECC decoder; the only work is routing decoded FECC commands to the layout engine. Fully predictable. This directly covers claims 3 and 11–12 (layout selection mode, layout change while in participant-selection mode), since RADVISION's layout set maps onto the claimed "set of layouts."

Combination 3 — Any of the above + a mode-shifted control paradigm (common knowledge)

The "mode" limitation. Claim 1's only arguably non-conventional element is that the MCU maintains a mode and re-interprets the same FECC message differently depending on that mode. A POSITA would find this obvious on two bases:

1. Mode-shifting a fixed keypad is a ubiquitous UI convention (TV/universal remotes, phone keypads, "shift"/"function" keys). Applying it to an FECC keypad to multiplex between camera-control, layout, and participant functions is an arbitrary, rote application of a known technique — obvious under KSR and MPEP 2144.04.
2. The claim's mode transitions are arbitrary and unclaimed in their specifics. Claim 1 does not recite which FECC control selects which mode; the specification expressly disclaims any fixed mapping ("different embodiments may define the FECC messages differently"). Arbitrary selection among equally viable alternatives is not inventive (In re Peterson; In re Harza).

Combining (3) with Combination 1 or 2 yields the full claim 1.

Combination 4 — H.245 conference-aware control + Annex Q FECC (for claims 31/36/41)

The Background admits H.245 lets a conference-aware terminal learn the participant list from the MCU, and the patent characterizes this as usable for participant selection. For claims 31/36/41, which add "participant selection mode + participant-to-participant camera control mode," combining H.245's participant list with Annex Q's FECC commands yields exactly the claimed two-mode apparatus. The patent's asserted advance — removing the need for conference-awareness — is a design simplification (moving intelligence from the endpoint to the MCU), which is obvious once the goal is stated.

6. Claim-by-claim disposition (preliminary)

7. Weaknesses, counterarguments, and what would defeat the rejection

A rigorous § 103 position must acknowledge what is not cleanly met:

1. No single reference teaches mode-dependent FECC interpretation. The references teach (a) layout/participant selection, and (b) FECC transport, but the retargeting of FECC messages to non-camera functions is the point of novelty. The rejection therefore rests entirely on motivation-to-combine, which is the vulnerable joint.
2. H.243 uses a different channel (H.230 BAS codes, not H.224/H.281 FECC). A patentee will argue H.243 teaches away from FECC-driven selection because H.243 already solved participant/layout selection via BAS for conference-aware terminals. The rebuttal: ETR 175 and the patent's own admission that ordinary H.323 endpoints lack conference-awareness defeat any teaching-away, and KSR discourages rigid "separate-embodiment" logic.
3. Secondary considerations. The patent asserts the benefit of not requiring conference-aware endpoints and no renegotiation. No evidence of unexpected results, industry praise, licensing, or copying appears in the record I retrieved. The litigation section found no asserting/accused activity in which such evidence would be developed — so there is currently no secondary-considerations record either way. Absence of secondary considerations cuts against patentability but is not affirmative evidence of obviousness.
4. Hindsight risk. The examiner allowed the case, and the specific "FECC-message-as-layout/participant-command" insight is easy to articulate only after seeing the claims. A court would require the motivation to be grounded in pre-2003 references — which ETR 175 and H.281's multipoint language supply. The strength of the rejection depends on documents like these, not on the patentee's own spec.
5. Post-2003 evidence of conventionality. Notably, later MCU products advertise "Layout control via FECC/DTMF" (Cisco TelePresence MCU admin guide: https://www.cisco.com/c/dam/en/us/td/docs/telepresence/infrastructure/mcu/admin_guide/...). This is after the 2003 priority date and therefore cannot be prior art to US 7,321,384 — but it corroborates that FECC-driven layout control became the industry-conventional solution, i.e., strongly suggests the 2003 step was an obvious one. Flag it as corroborative only, not citable as § 102/§ 103 art.

8. Bottom line

• The claims are, on the recovered language, broad, functional, and result-oriented, and the only non-conventional element is the mode-dependent reinterpretation of FECC messages.
• Strongest § 103 combination: H.243 Chair Control (participant/layout selection semantics) + H.281/H.224 and Annex Q (packet-network FECC transport, expressly designed for multipoint) + RADVISION on-the-fly MCU layout control (+ ETR 175's express motivation to give every user layout/participant control) + a mode-shifted keypad (common knowledge). Motivation to combine is supplied by the references themselves and by the patent's own admission that ordinary H.323 terminals are not conference-aware.
• Weaker points: no single reference discloses mode-dependent FECC handling; the rejection lives or dies on motivation to combine, and there is no secondary-considerations record either way.
• Caveats: (i) I recovered only part of the 47-claim set; a full verbatim copy should be pulled from USPTO PatentCenter before relying on this; (ii) I was unable to run the last round of targeted prior-art patent searches (step limit reached), so I have not yet identified specific pre-2003 US patents in this space — the above relies on the standard documents the patent itself cites plus ETR 175, H.281, and RADVISION; (iii) this is a technical analysis, not a legal opinion, and the patent carries a statutory presumption of validity that a challenger must overcome by clear and convincing evidence.

Recommended next steps to firm up the rejection: (a) pull the complete claims via USPTO Public PAIR/PatentCenter for 10/453,341; (b) search pre-2003 US patents assigned to PictureTel, Polycom, VTel, and RADVISION on MCU layout selection and remote camera control (e.g., via Google Patents "H04N7/152" + priority < 2003-06-03) to find patent-art counterparts to H.243's chair-control semantics; and (c) confirm the actual publication/priority dates of ETR 175 and the RADVISION viaIP datasheet (the 2003 date is close to the June 3, 2003 filing and should be verified as pre-filing).