Invalidity dossier

US 8635314

Use of IPv6 in access networks

Current assignee: Cisco Technology Inc

Added 8/27/2026, 6:42:26 PM

At a glanceNo PTAB challengesNo litigation on fileSoftware Technology & Computing Systems (T)

Active provider: DeepSeek · deepseek-v4-flash

Auto-generating section 1 of 2: Extensions

Each section takes ~30-60s with web-search grounding. Keep this tab open — sections will fill in below as they complete.

Patent summary

Title, assignee, inventors, filing/issue dates, abstract, and a plain-language overview of the claims.

✓ Generated

I'll search the USPTO and CAFC sources for the specific patent number 8635314.

Search Results

I searched for patent number 8635314 (and its publication number US8635314B2) specifically. I found authoritative records on Google Patents and Justia, plus inventor/assignee confirmation via PatentLeaderboard. The CAFC 2026 docket search returned no results — I found no indication of any CAFC appeal or 2026 litigation involving this patent number.

Important note on the rule about not auto-correcting IDs: I did not search for, or substitute, similar numbers (e.g., '5314, 8635314A1, or the parent '512 patent). All information below is specific to US 8,635,314 B2.


Summary of US Patent 8,635,314 B2

Field Data
Title Use of IPv6 in access networks
Assignee Cisco Technology, Inc. (original assignee per Google Patents; assignment data on record)
Inventors Ralph E. Droms; Madhu Sudan; Sanjeev Hemantkumar Desai; John T. Chapman; Raman S. Krishnan
Application / Filing date US 13/098,197, filed April 29, 2011 — a divisional of U.S. App. 11/302,966 (filed Dec. 13, 2005, now US 7,941,512 B2), which claims benefit of U.S. Provisional 60/635,995 (filed Dec. 13, 2004)
Issue date January 21, 2014
Legal status Google Patents lists "Expired – Fee Related," with adjusted expiration noted as 2026-02-25 — i.e., expired within the last two months as of today's date (2026-04-26). I could not independently verify the maintenance-fee history via USPTO Patent Center in this search, so treat the precise expiration/legal-status detail as subject to confirmation.
Claims 18 claims; independent claims: 1, 7, and 13

Abstract (as recorded on Google Patents):

"An apparatus may include a port to receive a ranging request from a cable modem and a processor in communication with the port. The processor may assign a service identifier to the cable modem, match the service identifier with a link layer address of the cable modem, receive a router advertisement and comparing the source link layer address from the router advertisement to the link layer address of the cable modem, and determine if the link layer address of the cable modem is the same as the source link layer address."


Plain-Language Overview of the Independent Claims

Claim 1 — Method (device-type detection via router advertisements):
A method in which a network element (e.g., a CMTS) (a) receives a ranging request from a cable modem, (b) assigns that cable modem a service identifier (SID), (c) links the SID to the cable modem's MAC address, (d) later receives a Router Advertisement (RA) and compares the RA's source MAC address (the MAC of the sender of the RA) against the cable modem's MAC address, and (e) determines whether the two MAC addresses are the same. In short: it detects whether the cable modem itself (as opposed to downstream CPE) originated the router advertisement, which reveals whether the modem is operating as a router.

Claim 7 — Apparatus (CMTS-implemented version):
The same method steps recited as performed by a "cable modem termination system (CMTS)" — i.e., a system claim covering the CMTS that receives the ranging request, assigns the SID, matches it to the modem's MAC, compares the RA's source MAC, and makes the same/different determination.

Claim 8–12 (dependent on claim 7): same/source-MAC-match determination outcomes, tagging the CM as a router when the MACs match, tagging CPE as a router when they don't, and determining CM boot mode (IPv4 vs. IPv6) from the version of the first relayed DHCP message.

Claim 13 — Apparatus (port + processor implementation):
A hardware claim: a port to receive the ranging request from the cable modem and a processor in communication with the port, programmed to assign the service identifier, match it with the modem's MAC address, receive the RA and compare the source MAC address, and determine whether the modem's MAC equals the source MAC.

Claim 14–18 (dependent on claim 13): mirror the same dependent concepts — finding the RA came from the modem when MACs match; finding it did not when they don't; tagging the CM as a router; tagging CPE as a router; and boot-mode detection (IPv4/IPv6) based on the first relayed DHCP message version.


Key Observations / Uncertainty

  • Scope note: The patent's written description (SUMMARY and DETAILED DESCRIPTION) discusses many broader embodiments — IPv6/IPv4 cable-modem provisioning via TFTP and management addresses, IPv6 flow-label downstream QoS classification, DHCPv6 prefix delegation, Mobile IPv6 home agents, TFTP/syslog server address options, etc. However, the granted claims are much narrower: all three independent claims are directed to the ranging-request/service-identifier/router-advertisement source-MAC comparison technique for detecting whether a cable modem or CPE is acting as a router.
  • Legal status uncertainty: The "Expired – Fee Related" status and 2026-02-25 adjusted-expiration date come from Google Patents. I could not access USPTO Patent Center directly in this search to confirm maintenance-fee events; a third-party snippet mentioning "PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES" appears on a related patent page and does not clearly refer to this patent, so I am not relying on it.
  • CAFC 2026: No results found for any appeal or docket involving this patent number in 2026.

Sources: Google Patents (https://patents.google.com/patent/US8635314B2/en), Justia Patents (https://patents.justia.com/patent/8635314), PatentLeaderboard (assignee/inventor/issue-date cross-check).

Generated 8/27/2026, 6:42:58 PM

Cases on file (0)

Specific litigation cases in our database that name US patent 8635314. The free-form analysis below may also discuss cases beyond this list.

No cases on file mention this patent. Upload a CSV or add a case manually in Admin → Manage litigation cases.

Litigation summary

Past and pending lawsuits — plaintiffs, defendants, jurisdictions, outcomes, and notable rulings.

✓ Generated

Based on my searches, I have not found any known litigation involving US Patent 8,635,314 B2 ("Use of IPv6 in access networks").

Search methodology and results

I ran multiple targeted searches, including:

  1. "8635314" patent litigation — returned only a PatentLeaderboard profile confirming the patent's existence (Cisco assignee, issued 2014-01-21, inventors Droms, Sudan, Desai, Chapman, Krishnan). No litigation hits.
  2. "8,635,314" lawsuit Cisco patent — returned unrelated Cisco patent cases involving different patent numbers (e.g., Paltalk v. Cisco over U.S. 6,683,858 in W.D. Tex.; CTD Networks v. Cisco et al. over U.S. 8,327,442 and 9,438,614; Enhanced Data Streaming v. Cisco over U.S. 9,185,151/RE50,398, 6,891,855, 7,336,605, 7,660,234, 7,032,135 in E.D. Tex.). None of these involve 8,635,314.
  3. "US8635314" OR "8635314B2" lawsuit OR litigation — returned zero results.
  4. "8,635,314" OR "8635314" patent case court docket — returned only the Google Patents record for the patent itself.
  5. Unified Patents portal search — returned no results for this patent number.

Conclusion

Item Finding
Known litigation involving US 8,635,314 None found
Plaintiffs N/A
Defendants N/A
Jurisdiction / case numbers N/A
Filing dates N/A
Outcome / status N/A

Caveats

  • Scope of search: I could not access PACER directly or the full Unified Patents/CAFC docket databases in these searches. The absence of results from public web searches is strong but not conclusive evidence of no litigation.
  • The patent's legal status is consistent with low litigation exposure: Google Patents lists the patent as "Expired – Fee Related" with adjusted expiration of 2026-02-25, and it has been expired (or in the fee-related expiration process) for roughly the last two months as of today's date (April 26, 2026). An expired patent has limited value as an assertion asset, which may explain the absence of litigation.
  • No CAFC appeal found: Consistent with the prior analysis section, no Federal Circuit appeal or 2026 docket entry involving this patent number surfaced.

If you need a definitive negative confirmation, the next steps would be a direct PACER query across all federal district courts (via the PACER Case Locator), the USPTO Patent Center litigation/assignment records, and RPX/DocketNavigator (subscription databases), none of which I could access directly in this session.

Generated 8/27/2026, 6:45:29 PM

Proceedings on file (0)

All PTAB activity →

AIA trial proceedings (IPR / PGR / CBM) filed at the USPTO Patent Trial and Appeal Board against this patent. Sourced from the USPTO Open Data Portal and refreshed every six hours; each proceeding number deep-links to the PTAB E2E docket.

No PTAB proceedings on file. This patent has not been challenged via IPR, PGR, or CBM. The absence is itself a signal — well-asserted patents eventually attract IPRs. The LLM analysis below may surface filings the ODP feed hasn’t indexed yet.

PTAB challenges

AIA trial proceedings at the USPTO Patent Trial and Appeal Board — IPR, PGR, and CBM. Petitioners, judge panels, claim-level invalidation outcomes from Final Written Decisions, and Federal Circuit appeals. The single most important defensive datapoint after litigation history.

✓ Generated

Proceedings overview

There are zero AIA trial proceedings on file for US 8,635,314 B2. The USPTO Open Data Portal (ODP) index returns no IPR, PGR, or CBM for this patent, and targeted web searches for "8635314" / "8,635,314" combined with IPR/PGR/CBM/PTAB terms surfaced no petition, no institution decision, no Final Written Decision, and no settlement referencing this patent. The breakdown by status is therefore: 0 active, 0 with claims invalidated, 0 with claims sustained, 0 settled, 0 institution-denied. The defensive posture this gives a defendant is neutral-to-favorable: the patent's 18 claims have never been tested before the PTAB — none are canceled, but none are battle-hardened either — and because no IPR has ever been filed, § 315(e)(2) estoppel does not bar any defendant from raising any prior-art ground in district court.

Note: I attempted verification via USPTO PTAB E2E/docket databases and multiple web sources. No proceeding numbers exist to report, so none are invented here. The one prior-art-adjacent hits (e.g., IPR2024-00505, IPR2025-00836, Cisco/Finjan IPRs) involve different patents and are not related to 8,635,314.


Individual proceedings

There are no proceedings to profile. Rather than fabricate a docket, the honest finding is:

  • No IPR, PGR, or CBM petition has ever been filed against US 8,635,314 B2.
  • No judge panel, no institution decision, no FWD, no settlement, no CAFC appeal exists for this patent.

Why this is plausible, not just an indexing gap:

  1. The patent is expired. Google Patents lists the status as "Expired – Fee Related," with an adjusted expiration date of 2026-02-25 — roughly six months before today (2026-08-27). The statutory IPR estoppel and remedy calculus changes dramatically once a patent is expired: no prospective injunctive relief, damages only for pre-expiration conduct, and diminished incentive for a would-be petitioner to spend six figures on an IPR when the claims are already unenforceable going forward.
  2. The claims are narrow. All three independent claims (1, 7, 13) are directed to a specific CMTS technique: matching a ranging request's service identifier to a cable modem's MAC address, then comparing the source MAC of a Router Advertisement to determine whether the CM itself (or downstream CPE) originated the RA. The expansive written description (IPv6 provisioning, flow-label QoS, DHCPv6 prefix delegation, Mobile IPv6 home agents, TFTP/syslog options) was never claimed in the granted patent — so the "juicy" subject matter that might attract a petitioner is outside the claims.
  3. Cisco is the assignee — a sophisticated operating company that licenses broadly and litigates rarely on this vintage of DOCSIS patent. Non-practicing-entity assertion campaigns (the usual IPR feedstock) are not evident for this patent.

Strategic summary

Claims: CANCELED vs. SUSTAINED vs. UNTESTED. All 18 claims (1–18) of US 8,635,314 B2 are UNTESTED before the PTAB. No claim has been canceled, no claim has been sustained in an IPR, and no claim has even been the subject of an instituted AIA trial. Independent claims 1, 7, and 13 — and their dependents 2–6, 8–12, and 14–18 — remain exactly as granted on 2014-01-21.

Estoppel landscape (§ 315(e)(2)). Because no IPR has ever been instituted, no petitioner, real party in interest, or privy is estopped from raising any ground against this patent. For a defendant facing assertion today, every avenue remains open: § 102 (anticipation), § 103 (obviousness), § 101 (patent-eligibility), and § 112 (indefiniteness/written description/enablement) can all be pressed in district court or via ex parte reexamination without any PTAB estoppel hangover. This is the rare case where the absence of IPR history is strategically liberating — the challenger's toolbox is completely full.

Pattern signals. There is no repeat-petitioner pattern, no Unified Patents involvement, and no PTAB-appeal history — because there is no PTAB history at all. The only "pattern" worth noting is the claim-scope mismatch: the patent's specification touts an IPv6 access-network architecture, but the granted claims are limited to a MAC-comparison/router-detection method. Any assertion built on the specification's broader IPv6 provisioning or QoS disclosure (rather than the ranging-request/RA source-MAC comparison) is vulnerable to a claim-construction and non-infringement attack independent of validity.

Cross-checking note (flag): The earlier patent summary in this analysis states "as of today's date (2026-04-26)," while this session's date is 2026-08-27. Both dates are after the 2026-02-25 adjusted expiration, so the expiration analysis is unaffected; the discrepancy is flagged for record-keeping only.


Recommended next steps

  1. There is no FWD to cite — say so plainly in any defense filing. A defendant should not imply PTAB scrutiny where none exists. The absence of IPR history cuts both ways: it means the claims are untested (weakness), but it also means no estoppel and no adverse PTAB findings to overcome (strength).

  2. If you are a defendant and the patent is asserted against you: (a) Confirm the maintenance-fee/expiration status directly in USPTO Patent Center (PAIR) — Google Patents' "Expired – Fee Related" (2026-02-25) should be verified because an expired patent caps exposure to pre-expiration damages and eliminates injunctive relief; (b) since no § 315(b) time bar or § 315(e)(2) estoppel applies to you, you are free to run your best prior art in district court — DOCSIS 2.0/3.0 specs, RFC 2461 (Neighbor Discovery / Router Advertisements), and Cisco's own uBR documentation are natural starting points for the ranging-request/SID/MAC-comparison claim elements; (c) consider whether an ex parte reexamination (which has no estoppel and no real-party-in-interest bar) is cheaper than district-court invalidity discovery for a patent this narrow.

  3. If you are evaluating acquisition/licensing of this patent: treat it as "all claims untested, expired (subject to confirmation), Cisco-origin, narrow DOCSIS claims." The practical enforcement value is low, and the $36.9M "approximate value" figure from PatentLeaderboard is an algorithmic estimate, not a market data point.

  4. Monitoring: because the ODP ingest can lag, a single re-check of the USPTO PTAB Trial Search (https://ptab.uspto.gov/) and Unified Patents PTAB portal for "8635314" at the time of any assertion is a cheap diligence step. As of today's searches (2026-08-27), both return nothing for this patent.

Bottom line: No PTAB proceeding exists on US 8,635,314 B2 — ever. A defendant faces a clean slate: no canceled claims, no estoppel, and a patent that (per Google Patents) expired on 2026-02-25. The absence of IPR activity is itself the signal: this is a low-value, expired, narrow Cisco patent that the marketplace has chosen not to attack.

Generated 8/27/2026, 6:45:47 PM

Assignment history

Inventors, original assignee, and the chain of ownership recorded with the USPTO — including the correspondent attorney who recorded each assignment, since shell-LLC chains often share one repeat-player attorney even when the entity names look unrelated. Surfaces NPE / patent-troll patterns: shell-entity transfers, known asserters in the chain, repeat correspondent fingerprints, pre-litigation assignments, and bankruptcy fire-sales.

✓ Generated

Flag on date discrepancy: The operating instructions set today's date as 2026-08-27, but the previously generated section states "as of today's date (2026-04-26)." I have treated 2026-08-27 as controlling; nothing in the analysis turns on the two-month difference.

Data-access caveat: I was able to search USPTO mirrors, Google Patents legal events, and third-party assignment indices, but I could not directly query the interactive USPTO Assignment Center (assignmentcenter.uspto.gov) in this session, so I cannot cite verified reel/frame numbers. Per the constraint against fabrication, I am reporting only what the available sources support.


Inventors

All five named inventors were Cisco employees at the time of filing (the patent issued to Cisco Technology, Inc., and each inventor's listed residence matches Cisco office locations):

Inventor Residence at filing Employer at filing
Ralph E. Droms Westford, MA Cisco Technology, Inc. (Cisco's Chelmsford/Westford area office)
Madhu Sudan San Jose, CA Cisco Technology, Inc.
Sanjeev Hemantkumar Desai Saratoga, CA Cisco Technology, Inc.
John T. Chapman Saratoga, CA Cisco Systems, Inc. — prolific cable-engineering author (93+ Cisco publications, CMTS/cable-modem focus)
Raman S. Krishnan Cupertino, CA Cisco Technology, Inc.

Unusual pattern? No. This is a classic in-house Cisco cable-access engineering team. John T. Chapman's publication record (CMTS, DOCSIS) confirms he remained a Cisco cable engineer for years after filing. I found no evidence of mass inventor departure within 12 months of filing, and no inventor-side assignment of rights away from Cisco.


Original assignee

  • Entity: Cisco Technology, Inc. (wholly owned subsidiary of Cisco Systems, Inc., San Jose, CA) — named as the original assignee on the issued patent and on the parent patent US 7,941,512 B2.
  • Product embodiment: Yes. The specification itself names Cisco's uBR10k and uBR7246VXR universal broadband routers (CMTS products) and Catalyst 3560/3750 switches, and the claimed "show cable modem" device-type detection (ranging request → SID → MAC match vs. RA source MAC) maps directly to Cisco's DOCSIS CMTS management feature set. Cisco shipped IPv6-capable CMTS platforms and DOCSIS cable-modem lines embodying this technology.
  • Current status: Operating. Cisco Systems, Inc. is a public company (NASDAQ: CSCO) and remains a going concern as of 2026; Cisco Technology Inc. is its in-force patent-holding subsidiary. No bankruptcy, dissolution, or divestiture found.

Assignment timeline

Finding: no recorded post-issuance assignments were surfaced for US 8,635,314 B2 in any source I could access.

  • Google Patents' legal-events tab for US8635314B2 shows only: application filed (2011-04-29), publication (2011-08-25), grant (2014-01-21), and adjusted expiration/status change (2026-02-25, "Expired – Fee Related"). No assignment events.
  • Searches of third-party assignment mirrors and USPTO index snippets returned zero records naming US 8,635,314 as the subject of any post-issuance conveyance.
  • The only assignment that must exist is the original employee-to-Cisco assignment covering the parent application US 11/302,966 (filed 2005-12-13), which by operation covers this divisional (13/098,197) since the inventors and assignee are identical. I could not verify a reel/frame number for that original assignment from the sources available, so I am not citing one.

This absence is itself a meaningful finding: the original assignee, Cisco Technology, Inc., still owns the patent, and the "Expired – Fee Related" status (adjusted expiration 2026-02-25) indicates Cisco let maintenance fees lapse rather than monetizing or transferring the asset.


Timeline diagram

timeline
    title Ownership of US 8635314
    2004 : Provisional filed by Cisco
    2005 : Parent application filed
    2011 : Divisional filed
         : Parent patent 7941512 issued
    2014 : US 8635314 issued to Cisco
    2026 : Expired fee related

NPE / troll-pattern signals

  1. Shell-entity transfernot present. No transfer to any LLC, IP-holding entity, or licensing vehicle appears in any record I could access. The chain terminates at Cisco Technology, Inc., an operating-company subsidiary that shipped the claimed CMTS products.

  2. Known asserter in the chainnot present. No entity on the Acacia / Marathon / IV / Wi-LAN / Conversant / Vringo / Innovatio / MPHJ / Round Rock / Spangenberg lists (or any Unified Patents / RPX high-frequency plaintiff list) appears in this patent's ownership history. Cisco itself is an operating company and is not a recognized NPE.

  3. Repeat correspondent across the chainnot present / unclear. With no recorded post-issuance conveyances, there is no correspondent chain to analyze. No attorney-of-record pattern can be established from the available data.

  4. Cascading transfersnot present. No chained assignments exist for this patent, in any time window.

  5. Pre-litigation transfernot present. No litigation naming US 8,635,314 was found in a CAFC docket search (prior section) or in general litigation-index searches, and there is no transfer dated near any suit. The patent's "Expired – Fee Related" status (2026-02-25) is affirmatively inconsistent with an active assertion campaign.

  6. Bankruptcy fire-salenot present. Cisco has not filed for bankruptcy; this patent was not sold in any insolvency proceeding.

  7. Privateeringnot present. No operating-company-to-NPE transfer exists, and no SEC filings (Cisco 10-K/8-K) surface any arrangement to have an NPE assert this patent on Cisco's behalf.

  8. Defensive aggregator (anti-NPE)not present as a transfer. The chain does not terminate at RPX, AST, LOT, Unified Patents, or OIN. (Cisco is a LOT Network member as a general matter, but there is no recorded transfer of this patent into a defensive aggregator, and the patent has simply lapsed.)


Verdict

Insufficient data (no records, or only the original assignment).

The verdict is driven by the absence of evidence: no recorded post-issuance assignments exist for US 8,635,314 B2 in any accessible source, so the ownership chain is a single link — inventors → Cisco Technology, Inc., an operating company that shipped CMTS products embodying the claimed ranging-request/SID/MAC-comparison technique. There is no NPE, no shell LLC, no litigation, no privateering, and no defensive-aggregator transfer in the record; the patent lapsed for non-payment of maintenance fees (adjusted expiration 2026-02-25), which is the behavior of a dormant operating-company asset, not an assertion vehicle. I could not directly query the USPTO Assignment Center to capture reel/frame numbers or a correspondent of record, so I am treating the chain as unverified-but-consistent rather than confirmed.

Verification link: https://assignmentcenter.uspto.gov/ (search patent number 8635314 — if the Assignment Center returns no conveyances, that confirms the finding above).

Generated 8/27/2026, 6:45:58 PM

Prior art

Earlier patents, publications, and products that may anticipate or render the claims unpatentable.

✓ Generated

I have to stop searching (tool-call limit reached), so I'll answer based on the confirmed data retrieved plus clearly-flagged analysis. I want to be transparent about one important gap: the full USPTO "References Cited" list for US 8,635,314 B2 was not retrievable in the searches I ran. The Google Patents record returned the specification text and the "Cited By" (later-citing) lists, but the examiner's "References Cited" section (the §102/§103 art) did not render in any search result. I will not fabricate specific examiner-cited patent numbers. Below is what is confirmed versus what is analysis.


1. Search-result caveat

Searches for US8635314B2, "8635314" "References Cited", and US7941512B2 (the parent) returned: the full patent text on Google Patents, the PatentLeaderboard records (assignee/inventor/issue date, value $36,957,000), and the later-citing patents. None returned the examiner's citation list for 8635314. So the "most relevant prior art" assessment below combines (a) references affirmatively incorporated in the patent's own text, and (b) analytic §102 mapping to the granted claims. Treat (b) as hypothesis, not a confirmed USPTO citation list.


2. Confirmed references from the patent's own specification (non-patent literature)

These are the only references the specification expressly names, and all predate the Dec. 13, 2004 priority date:

Reference Full citation Date Relevance to claims
RFC 2461 T. Narten, E. Nordmark, W. Simpson, Neighbor Discovery for IP Version 6 (IPv6), RFC 2461 December 1998 Defines the Router Advertisement (RA) message format and the Source Link-Layer Address option — i.e., the very field (source MAC/L2 address) that claims 1, 7, and 13 compare against the cable modem's MAC. Does not teach SID assignment or CMTS-side CM/CPE router detection. Potentially relevant to the "receiving a router advertisement and comparing a source MAC address" limitation under a §103 combination; alone it does not anticipate claim 1, 7, or 13.
RFC 2463 A. Conta, S. Deering, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6), RFC 2463 December 1998 Background for RA/ND messaging; same analysis as RFC 2461. Not anticipatory alone.
RFC 3513 R. Hinden, S. Deering, Internet Protocol Version 6 (IPv6) Addressing Architecture, RFC 3513 April 2003 Background only (128-bit address space discussion). Not anticipatory of the claimed method.

3. Confirmed later-citing references (NOT §102 prior art)

The Google Patents "Cited By (2)" section for US8635314B2 lists two patents that cite 8635314 as prior art against themselves. Both post-date the critical date, so they cannot anticipate 8635314:

  • US20130346629A1Cisco Technology, Inc., "Determining the type of upstream network address translation from a home gateway," priority 2012-06-26, published 2013-12-26.
  • US9438475B1 — Cisco Technology, Inc., "Supporting relay functionality with a distributed layer 3 gateway," filed 2014-04-01, granted 2016-09-06.

Their existence is useful only to show the technology direction (CMTS/home-gateway router-type detection, L3 gateway relay) in which later Cisco work built on this patent — not as prior art.


4. Analytic §102 prior-art assessment for the independent claims

The granted claims are narrow — all three independent claims (1, 7, 13) are the same invention in different statutory form:

  1. Claim 1 (method): receive ranging request from CM → assign SID → match SID to CM MAC → receive RA → compare RA's source MAC to CM MAC → determine same/different (i.e., detect whether the CM or downstream CPE is acting as a router).
  2. Claim 7 (apparatus/CMTS form): same steps, claimed as a system.
  3. Claim 13 (port + processor form): same steps, claimed as hardware.

Prior art that would need to disclose all elements to anticipate (§102):

  • CableLabs DOCSIS RFI specifications (SP-RFIv1.1, ~2001; SP-RFIv2.0, ~2002–2004). These public specifications govern DOCSIS cable-modem operation and teach, in detail: (i) the cable modem's ranging request during initialization, (ii) the CMTS assignment of a Service Identifier (SID) to the modem, and (iii) the CMTS's association of the SID with the modem's MAC address. That covers the first three limitations of claims 1/7/13. To my knowledge, DOCSIS 2.0-era specs did not teach the final RA source-MAC comparison for CM/CPE router-type detection — so DOCSIS alone would at most partially anticipate (elements 1–3) and would more likely be part of a §103 obviousness combination. If a pre-2004 DOCSIS document did teach the RA-based detection, it would be a strong §102(b) candidate against claims 1, 7, and 13; I could not confirm such a disclosure in this search.

  • RFC 2461 (above) + DOCSIS in combination: the classic §103 case — DOCSIS provides the SID/MAC infrastructure and ranging; RFC 2461 provides the RA with the source L2 address option. A skilled artisan combining them would reach the claimed comparison. This is the strongest obviousness theory against claims 1, 7, and 13, but it is a §103 analysis, not §102 anticipation by a single reference.

  • Cisco/CMTS vendor patents on "show cable modem" router detection or SID-to-MAC databases (e.g., Cisco's early CMTS patent portfolio from the late 1990s/early 2000s). Such references would be the most on-point §102 candidates for the full method (SID assignment + MAC matching + packet-classification by SID). However, I could not confirm any specific patent number from the USPTO citation list, and I will not guess numbers. If this matters for litigation/freedom-to-operate, the next step is to pull the PTO's citation list from USPTO Patent Center for US 13/098,197 or the parent 11/302,966 (US 7,941,512), which share the same specification and likely the same core art.


5. Claim-by-claim mapping (analysis, not confirmed citations)

Claim(s) Required elements Closest confirmed art Anticipation (§102) assessment
1, 7, 13 (independents) ranging → SID → SID/MAC match → RA → source-MAC compare → same/different DOCSIS RFI specs (elements 1–3); RFC 2461 (RA source-address field) No single confirmed reference teaches all elements; §102 anticipation not established on the confirmed record. §103 combination of DOCSIS + RFC 2461 is the strongest theory.
2–3, 8–9, 14–15 (same/different outcome) outcome of the MAC comparison Same as independents Anticipated if and only if the independent claim's reference also describes the outcome; no single confirmed reference does.
4, 10, 16 (tag CM as router) tagging the CM as a router when MACs match No confirmed reference Not confirmed in any retrieved reference.
5, 11, 17 (tag CPE as router) tagging CPE as a router when MACs differ No confirmed reference Not confirmed in any retrieved reference.
6, 12, 18 (boot mode) IPv4 vs. IPv6 boot mode from first relayed DHCP message version No confirmed reference Not confirmed in any retrieved reference.

6. Bottom line

  • Confirmed prior-art references on the record: only RFC 2461, RFC 2463, and RFC 3513 (incorporated by reference in the specification) — none of which alone anticipates claims 1, 7, or 13.
  • Most relevant analytic prior art: pre-2004 DOCSIS RFI specifications (ranging/SID/MAC-matching elements) in combination with RFC 2461 (RA source-MAC field) — a §103 obviousness theory against claims 1, 7, and 13, not a clean §102 single-reference anticipation.
  • Gap to close: the examiner's full "References Cited" list for US 13/098,197 (and parent 11/302,966 / US 7,941,512) must be pulled directly from USPTO Patent Center to identify any on-point Cisco/CMTS patents that may anticipate the router-detection claims. That list was not retrievable through the web searches performed today, and I have not guessed at patent numbers.

Sources: Google Patents (https://patents.google.com/patent/US8635314B2/en), including the full specification text (RFC 2461/2463 incorporations, "Cited By" list with US20130346629A1 and US9438475B1), and PatentLeaderboard records for the inventors.

Generated 8/27/2026, 6:46:15 PM

Obviousness

Combinations of prior art that suggest the claimed invention would have been obvious under 35 U.S.C. § 103.

✓ Generated

Obviousness Analysis — US 8,635,314 B2 ("Use of IPv6 in Access Networks")

1. Scope and effective date of the claims

The three independent claims — claim 1 (method), claim 7 (CMTS apparatus), and claim 13 (port + processor apparatus) — are substantively identical. Each requires: (a) receiving a ranging request from a cable modem; (b) assigning a service identifier (SID); (c) matching the SID with the cable modem's MAC address; (d) receiving a Router Advertisement (RA) and comparing the RA's source MAC address (i.e., the MAC of the sender of the RA) to the cable modem's MAC address; and (e) determining whether the two MAC addresses are the same — i.e., detecting whether the cable modem itself originated the RA, and thus whether the modem is operating as a router (as opposed to a bridge behind which CPE routers sit).

The claims are entitled to the December 13, 2004 priority date (via parent US 7,941,512 B2 and provisional 60/635,995), and the application (filed April 29, 2011) predates the AIA, so pre-AIA 35 U.S.C. § 103 and the Graham / KSR framework govern.

2. Level of ordinary skill in the art (PHOSITA)

A person with a B.S. in computer science, computer/electrical engineering, or equivalent, and 2–5 years of experience in broadband access networks, familiar with the CableLabs DOCSIS specifications (ranging, SID assignment, MAC-layer operation), the IETF IPv6 suite (RFC 2461 Neighbor Discovery, DHCPv4/DHCPv6 relay), and CMTS/CM provisioning and management (including show cable modem-style device inventory). This person would routinely consult both CableLabs and IETF standards.

3. Prior-art references available for combination

Because I could not retrieve the examiner's "References Cited" list for US 8,635,314 in this session, the analysis below uses the prior-art pool evidenced by the patent's own disclosures and by the search results:

Ref Reference Date / status Relevant teaching
R1 DOCSIS 2.0 Radio Frequency Interface Specification (CableLabs SP-RFIv2.0) Published before Dec. 2004 (well-known standard; the patent itself says CMs/CMTSs are "similar to those supported in current DOCSIS 2.0 specifications") Ranging procedure: CM sends RNG-REQ (ranging request); CMTS assigns a Service Identifier (SID); CMTS maintains a SID↔CM-MAC association; upstream packets are associated with a SID by the CMTS hardware
R2 RFC 2461, "Neighbor Discovery for IP Version 6 (IPv6)" (Dec. 1998) Published 1998; expressly incorporated by reference in the patent (FIG. 4 is "a router advertisement 400 according to RFC 2461") Defines the Router Advertisement (ICMPv6 type 134) and its Source Link-Layer Address option carrying the link-layer (MAC) address of the sender — i.e., the very "source MAC address" of the claimed RA
R3 US 7,290,046 B1 — "System and method for detecting customer premise equipment behind a router on a data-over-cable system" (AT&T) Issued Oct. 30, 2007 In a DOCSIS network, a head-end server compares the MAC address of the device that actually sent a message with an expected/encapsulated MAC address; if they differ, a router is present between CPE and CM. Directly establishes that MAC-comparison-based router detection in cable access networks was a known, desirable management technique
R4 US 8,117,279 B2 — same title as R3 Later AT&T patent (same family as R3) Same router-detection concept; supports R3's teachings (filing date not confirmed in this search — treat as corroborating, not load-bearing)
R5 US 7,647,786 B2 — "Neighbor discovery in cable networks" (Cisco) Filed May 25, 2004 (i.e., before the Dec. 13, 2004 priority date → pre-AIA § 102(e) prior art) A CMTS performing neighbor-discovery functions (ND proxy, DAD handling) in a cable network, examining ND/DAD messages from CMs/CPE and maintaining device records (title confirmed; full text not reviewed here)
R6 US 7,810,285 B2 — "Neighbor discovery proxy with distributed packet inspection scheme" (Cisco) Filed May 25, 2004 (§ 102(e) prior art) ND proxy with packet inspection at the CMTS (title confirmed)

Caveats: I verified R1, R2, and the substance of R3 from the search results; R5/R6 are identified from the Google Patents citation listing (titles confirmed, texts not reviewed in this session). The analysis does not depend on any single reference — the strongest ground is the combination.

4. Element-by-element mapping (claim 1)

Claim element Where taught
1(a) "receiving a ranging request from a cable modem" R1 (DOCSIS ranging; RNG-REQ)
1(b) "assigning a service identifier to the cable modem" R1 (CMTS assigns SID during ranging)
1(c) "matching the service identifier with a MAC address of the cable modem" R1 (SID↔MAC database; the patent's own description concedes this is conventional CMTS behavior: "the CMTS 200 creates an entry in a database matching the SID with the MAC address of the CM")
1(d) "receiving a router advertisement and comparing a source MAC address from the router advertisement to the MAC address of the cable modem" R2 supplies the RA and its source link-layer address; R1 supplies the stored CM MAC. The comparison is a trivial database lookup against an existing SID↔MAC table. R3/R4 supply the purpose (router detection by MAC comparison in a DOCSIS network)
1(e) "determining if the MAC address of the cable modem is the same as the source MAC address" Inherent in any equality check; explicitly motivated by R3/R4 (router present if MACs differ)

5. Primary obviousness combination: R1 + R2

Why the combination is natural, not inventive: The patent itself frames IPv6-in-DOCSIS as the problem space, and expressly builds FIG. 4 on RFC 2461 (R2). A PHOSITA deploying IPv6 Neighbor Discovery on a DOCSIS network would, as a matter of course, (i) already possess the CMTS's SID↔MAC database from DOCSIS ranging (R1), and (ii) receive RAs whose Source Link-Layer Address option (R2) exposes the sender's MAC. The only "step" added by the claims is comparing the RA's source link-layer address to a stored CM MAC — a routine database lookup producing an obvious yes/no answer.

Motivation: The stated operational need (in the patent's own Background/Detailed Description) — provisioning and managing "tens of thousands" of devices and distinguishing device types (CM Router vs. CPE Router behind a bridging CM) for show cable modem-style inventory and policy — is precisely the motivation R3 already documents for MAC-comparison router detection in DOCSIS networks. A PHOSITA wanting to know whether an RA came from the CM itself or from CPE behind it would apply the existing SID↔MAC association to the RA's source link-layer address. This is "obvious to try" with a predictable result under KSR: two known elements (DOCSIS SID/MAC tracking; IPv6 RA source-MAC field) combined for their known purposes.

The patent's own specification undermines inventiveness: The description presents the RA-source-MAC-vs-CM-MAC comparison as a straightforward extension of the CMTS's pre-existing ranging database ("the CMTS hardware is able to associate a SID with the received packet… The CMTS may then reference its database to determine if that MAC address matches that of the CM"). There is no showing of unexpected results, no technical hurdle overcome, and no new protocol invented — the RA and its source-MAC field already existed in RFC 2461.

6. Alternative/secondary combinations

  • R1 + R2 + R3 (or R4): R3 supplies an explicit, documented motivation: in a data-over-cable system, comparing the MAC of the message sender with a known MAC reveals whether a router sits between the CPE and the CM. Applying that known detection principle to IPv6 Router Advertisements (whose source link-layer address R2 already provides) is a straightforward substitution of the message type used for detection. This combination most directly reads onto the "tagging" dependent claims (CM tagged as router when MACs match; CPE tagged as router when they do not — claims 2–5), because R3's entire purpose is classifying devices behind/beyond routers.

  • R1 + R5 (or R6) + R2: R5/R6 already teach a CMTS that intercepts and processes IPv6 ND/DAD traffic in a cable network while maintaining per-device records. Adding the RA source-MAC comparison (R2) against the CM's MAC (R1) is an incremental, predictable enhancement of that ND-aware CMTS — the same network element, the same message family, the same database.

All three combinations render claims 1, 7, and 13 obvious, since the apparatus claims add only conventional hardware (a CMTS; a port and processor) performing the identical method — no non-obvious structural limitation.

7. Dependent claims

  • Claims 2–5 / 8–11 / 14–17 (same/different determination; tagging CM or CPE as router): These are the direct logical outcomes of the claimed equality test and are explicitly the raison d'être of R3/R4 (classify whether a device is behind a router). Obvious for the same reasons.
  • Claims 6 / 12 / 18 (determining CM boot mode — IPv4 vs. IPv6 — from the version of the first relayed DHCP message): CMTS DHCP relay for both DHCPv4 and DHCPv6 was well known by 2004 (dual-stack operation is the entire premise of the patent's disclosure), and inspecting the IP version of the first relayed message is a trivially predictable design choice. Obvious.

8. Counterarguments and rebuttal

  • "No single reference teaches the exact RA-source-MAC comparison." True, but § 103 does not require a single reference. The combination of R1 (database exists), R2 (RA carries source MAC), and R3 (MAC-comparison router detection is known and desirable in DOCSIS) fully supplies every limitation and the motivation. The claimed step is a predictable application of an existing field to an existing database.
  • Secondary considerations: No evidence of long-felt need, commercial success, licensing, or unexpected results was identified. Notably, the granted claims are far narrower than the specification's broad IPv6-in-access-network embodiments — consistent with claims having been narrowed during prosecution in response to art, and with the surviving subject matter being routine engineering.
  • Potential R3 date concern: If R3's earliest filing date postdates Dec. 13, 2004, it would not be § 102 prior art (I could not confirm its filing date in this session). This does not affect the primary R1+R2 ground, which stands alone: the SID↔MAC database and the RA source-MAC field make the comparison an obvious, indeed near-automatic, operation.

9. Conclusion

All three independent claims (1, 7, 13) and their dependents would have been obvious under pre-AIA 35 U.S.C. § 103 to a PHOSITA as of December 13, 2004. The strongest ground combines the DOCSIS 2.0 RFI specification (ranging request, SID assignment, SID↔MAC matching) with RFC 2461 (Router Advertisement and its source link-layer address), optionally reinforced by US 7,290,046 B1 (known MAC-comparison router detection in data-over-cable systems) and Cisco's neighbor-discovery-in-cable-network patents (US 7,647,786 / US 7,810,285). The claimed invention is the predictable application of a standard IPv6 message field to a pre-existing DOCSIS management database, for a purpose — device-type/router detection — that the prior art already recognized and solved by MAC comparison.

Key sources: Google Patents US8635314B2 (https://patents.google.com/patent/US8635314B2/en); US 7,290,046 B1 (https://patents.google.com/patent/[US7290046B1](/patent/US7290046B1)/en; https://uspto.report/patent/grant/[7290046](/patent/7290046)); US 8,117,279 B2 (https://patents.justia.com/patent/[8117279](/patent/8117279)); RFC 2461 (IETF, Dec. 1998); Cisco ND-in-cable patents per the Google Patents family-citation listing for US8635314B2.

Generated 8/27/2026, 6:47:00 PM

Extensions

Patent term adjustments, term extensions, continuations, divisionals, family members, and expiration dates.

Not generated yet. Click Generate to call the active LLM provider with the configured prompt.

Derivative works

Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.

Not generated yet. Click Generate to call the active LLM provider with the configured prompt.

Keep exploring

Other patents in Software Technology & Computing Systems (T)

See all Software Technology & Computing Systems (T) patents →