Patent Drafting Analysis of Cypress Semiconductor’s Multi-Protocol Communication Network | US 2024/0251290 A1
Patent Drafting Analysis of Cypress Semiconductor's Multi-Protocol Communication Network | US 2024/0251290 A1
A structural and strategic analysis of US 2024/0251290 A1 covering claim architecture, drafting quality, critical gaps, and prosecution positioning for Cypress Semiconductor's USB-to-RF wireless bridging technology.
Spec Words
4,850
Across 6 sections
Draft now ↗
Total Claims
20
3 independent · 17 dependent
Draft now ↗
Figure Sheets
4
System architecture, packet diagrams, state diagram, hub block diagram, method flowchart
Draft now ↗
Published by PatSnap Insights Team · · 12 min read Verified by PatSnap Eureka Data
Overview
Structural Overview
The detailed description dominates at approximately 45% of total words (~2,200 of ~4,850), with the claims section contributing a substantial ~30%, reflecting the drafting team's emphasis on procedural method recitations. The patent presents 20 claims — 3 independent method claims and 17 dependent claims — structured entirely as method claims with no apparatus or system claim type diversity. Figure coverage spans 4 sheets across 5 figures addressing the system architecture, packet format transformations, state machine, hardware block diagram, and method flowchart, providing solid but not comprehensive structural support.
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 4 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1 | Block diagram of the multi-protocol communication network 100, showing first device 102 with wireless Tx/Rx 104 and interface controller 106, second device 112 with wireless Tx/Rx 114 and interface controller 118, connected over wireless channel 116.Search in Eureka ↗ | System architecture |
| FIG. 2 | Schematic block diagrams illustrating RF packet formats — first wired protocol packet 202 (preamble S 204, data 206), first wireless protocol packet 208 (preamble P+C 210, data 212), second wireless protocol packet 214, and second wired protocol packet 220 with synchronization bits Sбх 222 removed.Search in Eureka ↗ | Claim support |
| FIG. 3 | State diagram showing operational states and transitions of the multi-protocol communication network 100 including OFF/RESET 302, IDLE 306, SCAN/BEACON 310, RF-ON USB-OFF 314, USB RF-ON USB-ON 320, and USB-Suspend 330 states with labeled transition conditions.Search in Eureka ↗ | Flow diagram |
| FIG. 4 | Block diagram of the wired-to-wireless hub/router 400 showing USB interface 402 with CPU subsystem 410, I/O subsystem 412, 60G RF radio 404, system and peripheral interconnect 406, and system resources 408 including power, clock, reset, and test subsystems.Search in Eureka ↗ | Key embodiment |
| FIG. 5 | Flowchart illustrating the method of operating the multi-protocol communication network, showing steps 502–512 from establishing wireless connection through packet conversion with synchronization bit insertion/removal to exchanging keep-alive RF packets.Search in Eureka ↗ | Flow diagram |
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Claims
Claim Architecture Analysis
The patent presents exactly 3 independent claims — Claims 1, 13, and 18 — all of which are method claims, with no independent apparatus or system claim type filed. The dependent:independent ratio of 5.67:1 is near the lower bound for the wireless communications IPC class (H04W), where ratios of 6–12:1 are common, suggesting a modestly thin dependent claim layer. Notably, Claims 1 and 13 cover USB-over-wireless scenarios using general wireless and specific RF wireless protocol language respectively, while Claim 18 re-casts the same invention specifically as an RF/USB-connection method, providing incremental but not structurally distinct fallback coverage.
Core inventive concept: The claims address the latency problem caused by buffering non-USB (e.g., UART/PCM) data before transmitting USB packets over a shared RF wireless link, solved by proactively "inserting a number of synchronization bits in a preamble field of the first-packets" before a full data portion is received, so that second-packet duration aligns with wireless-protocol packet timing and USB packets are never delayed waiting for the wired interface to complete. This mechanism — sensing preamble arrival and immediately beginning preamble transmission with sync-bits embedding non-packet data — is the core limitation in Claims 1, 13, and 18.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | A method for operating a multi-protocol communication network | comprising | transmitting PAIR-Req from first transceiver to second transceiver using packet-switched wireless protocol; establishing wireless-connection on response; initiating USB-connection via USB-Req from first interface-controller; transmitting USB-Req to second interface-controller; second device establishing USB communication; converting USB-packets to second wireless-packets by inserting synchronization bits in preamble field aligned with first wireless-packet durationSearch prior art ↗ |
| Claim 13 | A method for operating a multi-protocol communication network | comprising | exchanging first wireless-packets between transceivers to establish wireless-connection; receiving first wired-packets from first wired-connection via interface-controller using packet-switched-wired-protocol; converting first wired-packets to second wireless-packets by inserting synchronization bits in preamble field aligned with duration of first wireless-packets; transmitting second wireless-packets; converting received second wireless-packets to second wired-packets by removing synchronization bits; transmitting second wired-packets to second wired-connectionSearch prior art ↗ |
| Claim 18 | A method | comprising | exchanging RF-packets between first and second device using packet-switched-RF-protocol; receiving data from first wired-connection including USB-packets and non-packet based data; converting USB-packets to second RF-packets by inserting synchronization bits in preamble field to align packet duration with first RF-packets; transmitting second RF-packets; re-converting second RF-packets to USB-packets by removing synchronization bits; coupling USB-packets to second wired-connection to establish USB-connectionSearch prior art ↗ |
Claim Dependency Tree
1 Method: multi-protocol network — PAIR-Req wireless pairing, USB-Req initiation, sync-bit preamble insertion for USB-to-wireless packet conversionSearch Claim 1 prior art ↗
2 Adds: re-converting second wireless-packets to USB-packets at second device by removing synchronization bits from preamble fieldSearch in Eureka ↗
3 Adds: synchronization bits include bits of non-packet based data accumulated in first deviceSearch in Eureka ↗
4 Further: non-packet based data comprises UART or PCM dataSearch in Eureka ↗
5 Further: if USB communication suspended, idling interface-controllers and transmitting accumulated non-packet data as third wireless-packets to maintain wireless-connectionSearch in Eureka ↗
6 Further (dep. on 5): if USB-packets received, awakening interface-controllers and re-establishing USB communicationSearch in Eureka ↗
7 Further (dep. on 5): if USB suspended for first predetermined time, resending USB-Req through wireless-connectionSearch in Eureka ↗
8 Further (dep. on 7): if second device does not respond within second predetermined time, idling transceiversSearch in Eureka ↗
9 Further (dep. on 8): after idled for third predetermined time, re-transmitting PAIR-Req and re-initiating USB-connection if pairedSearch in Eureka ↗
10 Adds (dep. on 5): if wireless-connection interrupted for first predetermined time, idling both transceiversSearch in Eureka ↗
11 Further (dep. on 10): after idled for second predetermined time, re-transmitting PAIR-Req and re-initiating USB-connection if pairedSearch in Eureka ↗
12 Adds (dep. on 1): converting USB-packets to second wireless-packets comprises sensing reception of first USB-packet, inserting sync bits, and beginning preamble transmission without waiting for data portionSearch in Eureka ↗
13 Method: multi-protocol network — wireless-packet exchange, wired-packet receipt, sync-bit preamble insertion for duration alignment, bidirectional conversionSearch Claim 13 prior art ↗
14 Adds: received data further comprises non-packet based data, synchronization bits include bits of that non-packet dataSearch in Eureka ↗
15 Further: non-packet based data comprises UART or PCM dataSearch in Eureka ↗
16 Further: if wired communication suspended, exchanging third wireless-packets comprising accumulated non-packet data to maintain wireless-connectionSearch in Eureka ↗
17 Adds: converting first wired-packets to second wireless-packets comprises sensing reception, inserting sync bits, beginning preamble transmission without waiting for data portionSearch in Eureka ↗
18 Method: RF-specific — RF-packet exchange, USB+non-packet data receipt, sync-bit insertion for RF-packet duration alignment, USB-connection establishmentSearch Claim 18 prior art ↗
19 Adds: data further comprises non-packet based data for RF-connection; synchronization bits include bits of non-packet dataSearch in Eureka ↗
20 Further: converting USB-packets comprises sensing USB-packet reception, inserting sync bits, beginning preamble transmission without waiting for data portionSearch in Eureka ↗
| Metric | This Application | Wireless Comm. Industry Norm |
|---|---|---|
| Total claims | 20 | 15 – 30 |
| Independent claim count | 3 | 2 – 5 |
| Dependent : Independent ratio | 5.67 : 1 | 5 – 10 : 1 |
| Method claims present? | Yes — Claims 1, 13, 18 | Common |
| System / apparatus claims? | No | Common |
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Drafting Quality
Drafting Quality Signals
The specification provides solid support for the synchronization-bit preamble insertion mechanism across FIG. 2 and paragraphs [0025]–[0028], and the proactive preamble start limitation in Claims 12, 17, and 20 is well-anchored in paragraphs [0028] and [0030]. A significant structural weakness is the complete absence of apparatus or system claims, which exposes the patent to straightforward design-around by competitors manufacturing the hardware without performing the recited method steps.
✅
Antecedent Basis
Antecedent basis is generally clean across the 20 claims. Claim 1 introduces "a first transceiver," "a first device," and "a second-transceiver" with proper indefinite articles, and subsequent references use "the first transceiver" and "the second-transceiver" consistently. Claim 13 similarly introduces "a first transceiver" and "a second-transceiver" independently without relying on Claim 1's antecedents, as appropriate for an independent claim. The only minor potential issue is that Claim 18 introduces "a first device" and "a second-device" but then refers to "the first wired-connection" without explicitly introducing it in the preamble, though context from the body establishes this sufficiently.
✅
Spec–Claim Consistency
The core limitation of inserting synchronization bits in a preamble field maps directly to FIG. 2 (packet 208 showing preamble P+C 210) and paragraphs [0025]–[0028], which explain the sync-delay δsd and the construction of the first wireless protocol packet. The "proactive preamble start" limitation in Claims 12, 17, and 20 maps to paragraph [0028] which explicitly states "minimized proactively starting a preamble transmission." The USB-connection state machine in Claims 1–11 is supported by FIG. 3 and paragraphs [0029]–[0035]. All major claim elements have identifiable paragraph-level spec support.
✅
Transition Word Usage
All three independent claims (1, 13, 18) use "comprising" as the transition, which is strategically optimal for this invention — it permits additional protocol steps or hardware elements not recited in the claims without negating infringement. No "consisting of" or "consisting essentially of" language appears, which is appropriate given the open-ended nature of multi-protocol communication networks that may involve additional layers or protocols not enumerated. This is a correct and defensible transition word choice across the claim set.
✅
§112(f) Means-Plus-Function Risk
No "means for" or "step for" language appears anywhere in the 20 claims, and functional labels such as "interface-controller" and "transceiver" are used as structural nouns rather than functional claim elements. The term "interface-controller" could theoretically attract §112(f) scrutiny if read as a nonce word, but it is sufficiently structural in context — the spec at paragraphs [0022] and [0039] provides hardware-level description of the USB interface 402 and its I/O subsystem 412 components. The §112(f) risk is low for this claim set.
⚠️
§101 Eligibility Risk
Although all claims are method claims directed at a communication network, the recited steps — converting packets, inserting bits, transmitting, and re-converting — are inherently tied to physical hardware transceivers and physical RF wireless channels, providing a meaningful hardware tie-in that should satisfy the machine-or-transformation prong under Alice/Mayo. However, Claims 13 and 18 are more abstract in their preamble language ("A method for operating" and "A method comprising" respectively) and do not explicitly name physical hardware components in the preamble, which could invite an examiner to characterize them as abstract process claims. The absence of apparatus claims means any §101 rejection cannot be worked around by pointing to a system counterpart.
⚠️
Dependent Claim Fallback Quality
Claims 3–4 (UART/PCM non-packet data) and Claims 5–11 (suspend/wake/re-pair state machine) add genuinely distinct fallback positions that capture unique operational scenarios. However, Claims 13–17 and Claims 18–20 largely re-draft the same core invention of Claims 1–12 in slightly different language, with Claims 15 and 4 being substantively identical UART/PCM limitations and Claims 17 and 12 being substantively identical proactive-preamble limitations. This structural duplication consumes claim count without creating meaningfully different prosecution fallback positions.
⚠️
Abstract Quality
The abstract accurately describes the core mechanism — inserting synchronization-bits non-packet data in a preamble initiated on sensing arrival of the preamble — and specifically names the latency improvement as the technical benefit. However, the abstract does not identify the number-selection criterion for synchronization bits (alignment with wireless-protocol packet duration) as the novel contribution, which is the key distinguishing limitation over prior art buffering approaches described in the background. An examiner reading only the abstract might characterize this as a generic packet-format conversion method rather than identifying the duration-alignment synchronization mechanism as the inventive step.
⚠️
Figure Support Quality
FIG. 2 directly supports the synchronization bit insertion and removal mechanism claimed in all three independent claims, and FIG. 5 supports the method steps of Claim 13. However, the state machine transitions recited in Claims 5–11 (USB-suspend, USB-wake, re-pairing) are supported only by FIG. 3 at a high state-diagram level without any figure showing the actual packet flow or timing during these state transitions. Additionally, no figure shows the apparatus structure — the wired-to-wireless hub — performing the claimed method steps in a way that would support apparatus claims if continuations are filed, and FIG. 4's hub block diagram is described but not fully cross-referenced to any specific claim limitation.
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Scorecard
Strategic Intent Scorecard
Multi-dimensional assessment of this application's patent strategy quality, based on claim structure, specification depth, and prosecution positioning.
Claim Breadth
3.5
Prosecution Defensibility
3.2
Spec–Claim Consistency
3.8
Dependent Claim Coverage
3
Claim Type Diversity
1.5
Figure Support Quality
3.2
Key observation: Spec–Claim Consistency scores highest (3.8/5) because the synchronization-bit preamble insertion mechanism is specifically mapped to FIG. 2 and paragraphs [0025]–[0028], giving the claims strong written description support for the core limitation. Claim Type Diversity scores lowest (1.5/5) because all 20 claims are method claims — the complete absence of apparatus, system, or computer-readable medium claims creates a significant design-around opportunity for manufacturers of the wired-to-wireless hub hardware who can argue they sell a product rather than perform a method. Practitioners analyzing this filing should prioritize filing continuation applications with apparatus claims directed to the hub/router of FIG. 4 and the interface-controller structure described in paragraphs [0038]–[0043].
See how your own draft compares — Open Eureka IP Drafting →
Critical Gaps
3 Critical Gaps in This Claim Set
A senior-attorney lens on the three highest-priority structural weaknesses — what each exposes in prosecution and litigation, and what a stronger filing would have done differently.
🔒
3 Critical Gaps in This Claim Set
See the full attorney-level analysis of what this application leaves unprotected — and how to draft it more defensively for your own filings.
No apparatus claims on hub hardware Three independent claims duplicate scope Sync-bit count selection algorithm unclaimed
Unlock Full Analysis — Free Frequently asked questions
US 2024/0251290 A1 — key questions answered
Still have questions? PatSnap Eureka can answer them from patent data instantly. Search in Eureka
Disclaimer: This analysis is generated by PatSnap Eureka AI based on publicly available patent data from the USPTO. It does not constitute legal advice and should not be relied upon as such. Patent data may be subject to change as prosecution progresses. Scores and assessments reflect automated analysis and may not capture all relevant legal or technical nuances. Always consult a qualified patent attorney for formal legal opinions on patentability, freedom to operate, or infringement.
Ask anything about this patent.
PatSnap Eureka searches patents and data to answer instantly.
PatSnap Eureka searches patents and data to answer instantly.
Powered by PatSnap Eureka
Link copied to clipboard