US 7289456

I'll verify the patent record and check for any 2026 CAFC activity on this specific number before summarizing.

The initial searches returned irrelevant hits. Let me run more targeted queries, including the specific CAFC/CourtListener string.

US Patent 7,289,456 — Concise Summary

Sourcing note and date flag

This summary is grounded in the authoritative full text supplied for this patent (fetched from https://patents.google.com/patent/[US7289456](/patent/US7289456)/en), which I treat as controlling over search results. One housekeeping contradiction to flag up front, consistent with the earlier sections: the header of this task states the current date is April 26, 2026, while the system date and the previously generated sections use 2026‑09‑27 / 2026‑09‑29. The patent record is the same either way; only the "as‑of" date differs.

Identifier discipline: I interpreted the query string literally. 7289456 resolves to exactly one document, US 7,289,456 B2 (application 10/118,187). I did not substitute any look‑alike number. In particular I excluded US 7,027,465 (a different Telcordia routing/provisioning family member), US 7,881,229 (a later patent that cites '456), and US RE43,704 E1 (the reissue in this same family, a separate document — not to be confused with RE44,904, which belongs to the CommWorks Wi‑Fi portfolio). Search hits for the bare string "7289456" produced unrelated items (e.g., a Brazilian trademark/registry entry, INPI mark records) which I disregard.

---

Bibliographic summary

Confidence note: The title, dates, inventors, assignee, and abstract below are [verified] from the supplied authoritative text. The "current assignee" field and the reissue relationship are reported as the record states them; the earlier Assignment section found the full proprietary chain runs Telcordia → Telcordia Licensing (2009) → TTI Inventions A (2010) → Nytell (2015) → CommWorks (2020). Reel/frame detail was not retrievable and is not asserted here.

---

Abstract (verbatim, as recorded)

"A graph of a network is created by efficiently modeling the network elements, and the network links and virtual trunks that interconnect these elements. The network elements are model as one or more routing nodes wherein each routing node represents part of an element or a set of one or more elements, and has the characteristic that any ingress and egress ports of the network element or network elements associated with the routing node can be interconnected. The network links and virtual trunks are both modeled as routing links, wherein routing links interconnect the routing nodes to create the graph of the network. The graph is subsequently used for determining routing paths through the network for the provisioning of virtual trunks and circuits."

(The grammatical slips — "are model as," "has the characteristic" — appear in the printed abstract; I have not corrected them.)

---

Plain-language overview of each independent claim

The patent has 28 claims. The independent claims are 1, 5, 9, 11, and 22. Claims 1–21 are fully set out in the supplied text; claims 22–28 are truncated in the source (the text for claim 22 cuts off mid‑sentence), so my overview of claim 22 is necessarily partial and I cannot describe 23–28 substantively. [Flagged as a gap, not filled in by inference.]

Claim 1 — System for establishing a path (the core system claim).
A provisioning system with three cooperating parts: (a) an inventory subsystem that models the network as a graph of nodes and links; (b) a routing engine that uses that graph to find a path between two points; and (c) a service activation system that calls the routing engine, takes the returned path, and derives from it (plus the model) a set of network‑element cross‑connections to actually stand up a virtual connection. The defining limitation is the node definition: each graph node represents a partial network element, a single network element, or a group of network elements, and any combination of that node's edge ports that can be interconnected is treated as interconnectable — i.e., the node is drawn as a coarse "any‑to‑any" cross‑connect box rather than one node per port.

Claim 5 — System with alternate paths (the core multi‑path system claim).
Same architecture and same node definition as claim 1, but adds multi‑path routing: the routing engine returns an initial path plus one or more secondary paths, and the service activation system chooses a preferred path from among them, then derives the cross‑connections needed to establish the virtual connection over that preferred path.

Claim 9 — Method for building the graph (classification‑driven node creation).
A method of creating the network graph: (1) determine a "routing model" for a network element — a classification describing how that element's ports can be interconnected among themselves and with other elements; (2) based on that model, decide whether the element should be grouped with other elements and represented collectively as a single routing node; if so, check whether a routing node already exists for that group and, if not, decide whether one should be created; (3) if the element is not to be grouped, decide whether it becomes one node or several nodes, and create it/them; (4) represent each network link as a routing link; and (5) associate each routing link with the two routing nodes it joins, thereby building the graph.

Claim 11 — Method for determining a path.
The method mirror of the system claims: model the elements as routing nodes (each node = a partial element, a single element, or a set of elements; any interconnectable edge ports of the represented thing are treated as interconnectable); model each physical link as a routing link interconnecting nodes; and determine the path by finding the set of routing nodes and routing links that interconnect the two endpoints.

Claim 22 — Second method for determining a path. (Partial — source text truncated.)
Claim 22 repeats the modeling and path‑determination steps of claim 11 and then adds a step directing "determining from the determined set of routing nodes and routing links a set of network …" — the sentence cuts off in the supplied text. On the visible portion, claim 22 appears to be claim 11 plus derivation of network‑element cross‑connections (i.e., the provisioning step), but I state that as an apparent reading only. I cannot describe claims 23–28 because their text is not in the source I was given.

How the independent claims interlock (context from the dependents, for orientation only): claim 2 models a provisioned virtual trunk as a routing link; claim 3 adds an element adapter that translates the cross‑connections into device commands; claim 4 adds a per‑cross‑connection status database enabling partial re‑provisioning; claims 6–8 cover fallback to an alternate path, bandwidth‑aware selection, and computing secondary paths via the destination node's neighbors; claims 13–16 map the four "routing models" onto the node abstraction (common management entity → one node; multi‑chassis interconnected element → one node; daisy‑chained elements → one node; independent chassis → one node per chassis).

---

USPTO / CAFC 2026 docket check for "7289456" (specific number only)

I ran targeted searches on the exact number and returned no citable result. Being explicit about what that does and does not establish:

• No CAFC 2026 docket naming this patent was found. My queries ("7,289,456" + Federal Circuit 2026 appeal; the bare string via CourtListener‑oriented queries) returned zero relevant hits — the results were other parties' 2026 Federal Circuit matters (e.g., Contour IP Holding v. GoPro, Nos. 2026‑2012; Netlist/Micron‑type updates; Finnegan's and Gibson Dunn's 2026 Fed. Cir. statistics and case roundups), none of which involves this patent number. This is consistent with the earlier Litigation and PTAB sections, which likewise found no proceeding or suit tied to this specific patent.
• Search-engine negative ≠ authoritative negative. A web/string search of CourtListener, PACER aggregators, and PTAB sources is not a substitute for a direct docket query. The controlling checks are CourtListener/PACER full‑text for the literal strings "7,289,456" and 7289456, the USPTO PatentCenter/Assignment records for app. 10/118,187, and — critically — a separate query on the reissue RE43,704, because an assertion or appeal could name the reissue rather than the original.
• Practical context: the record shows the patent ceased with an adjusted expiration of 2024‑09‑20, which sharply limits any new 2026 assertion or appeal on this document. Any 2026 CAFC activity would most plausibly arise from a long‑running case filed before expiry, or from the reissue — neither of which I could confirm.

---

Uncertainty ledger

1. Claims 22–28 are truncated in the supplied source; claim 22 is described only partially and 23–28 are not analyzed. (Authoritative text gap.)
2. No confirmed 2026 (or any) Federal Circuit / district‑court matter naming 7,289,456 — a negative from non‑authoritative searches, not a verified docket result.
3. Reissue coverage gap: US RE43,704 E1 is a same‑family document with its own number; a search on "7,289,456" would not catch activity on the reissue.
4. Assignee fields reflect the record as given; revenue‑interest/ownership nuance and reel/frame detail were not retrievable and are not asserted.
5. I have not invented any reference numbers, claim text, case captions, or dates to fill the gaps above.

I'll search for litigation specifically naming US 7,289,456, using litigation-focused sources.

Let me search litigation-specific databases and the assignee's known campaigns.

Let me run additional targeted checks on litigation databases and the reissue counterpart.

Known litigation involving U.S. Patent No. 7,289,456 — answer: none found

I searched litigation-focused sources (Unified Patents litigation materials, CourtListener/RECAP dockets, Justia, RPX/Insight, PACER-derived aggregators, the Darts-IP family link, and CAFC opinions) for the literal strings "7289456" and "7,289,456." No district-court case, ITC investigation, PTAB proceeding, or CAFC appeal could be confirmed that names U.S. Patent No. 7,289,456 as an asserted or challenged patent. I am therefore returning a negative finding rather than a fabricated case list.

Below is (A) the auditable basis for the negative, (B) the false positives I affirmatively excluded so you do not chase them, and (C) the adjacent litigation in this patent's family/assignee lineage that a reader could easily mistake for '456 activity.

---

A. What was searched (and the result)

Bottom line: because Google Patents' "Family has litigation" flag is family-level, it is not evidence that '456 itself was asserted. No case specific to '456 surfaced.

---

B. False positives I excluded (do not conflate)

These are the traps that produce a false "positive" if you search only the shorthand "'456":

1. Corning fiber-optic "'456 patent" (ITC/PTAB records). Several PTAB petition documents refer to a "'456 Patent" about fiber optic equipment trays / 98–144 connections per U space, challenged using US 7,570,861 (Smrha). That is a Corning optical-connectivity patent — a different document entirely, not US 7,289,456. The asserted claims there are 11, 12, 14–16, 19, 21, 27, 28 — unrelated to the network-routing claims of '456.
2. US 6,725,456 (Bruno et al.) and the "the '946 patent" (IPR2024-01250) references — different patents (QoS/API and multi-user detection, respectively).
3. Brazilian/administrative records (INPI trademark PDFs, SINREM notices) that merely contain the digit string "7289456" — not patent litigation.

---

C. Adjacent litigation in the family / assignee lineage (these name other patents)

To be complete, here is the enforcement activity surrounding this patent. None of these assert US 7,289,456.

(1) Telcordia Technologies, Inc. — D. Del. (2004–2010). The original assignee's enforcement campaign:

• Telcordia Technologies, Inc. v. Alcatel S.A. and Alcatel USA, Inc. — D. Del., C.A. No. 04-874-GMS (defendant Alcatel later stayed its case).
• Telcordia Technologies, Inc. v. Lucent Technologies Inc. — D. Del., C.A. No. 04-875-GMS.
• Telcordia Technologies, Inc. v. Cisco Systems, Inc. — D. Del., C.A. No. 04-876-GMS.
• Parallel ITC action, and a Federal Circuit appeal reported at 612 F.3d 1365 (Fed. Cir. 2010).
• Asserted patents: US 4,893,306 ('306, DTDM multiplexing), Re. 36,633 ('633, SRTS timing), and US 5,706,763 ('763, self-healing ring). Accused products included Lucent CBX-500, GX-550, and Cisco switches. Outcome (distilled from the record): mixed — Telcordia took adverse summary-judgment rulings on '306 claims and the appeals continued. No '456 patent appears in these records.

(2) CommWorks Solutions, LLC — present-day campaign (this patent's current owner). CommWorks acquired the Telcordia/IV portfolio in 2020-01-03, but the patents it asserts are '249 (6,832,249), '465 (7,027,465), '285 (7,177,285), '596 (7,463,596), '979 (7,911,979), '664 (7,760,664), RE44,904, and 8,923,846:

• CommWorks Solutions, LLC v. Comcast Cable Communications, LLC, et al. — W.D. Tex., 6:21-cv-00366, filed 4/15/2021; patents '249, '465, '285, '664, '846; dismissed 7/1/2022 (order granting motion to dismiss, Dkt. #50).
• CommWorks Solutions, LLC v. NextLink / EarthLink — E.D. Tex.; patents '249, '807, '465.
• CommWorks Solutions, LLC v. STMicroelectronics, Inc. — W.D. Tex., 7:25-cv-00363, filed 8/25/2025; patents '285, '596, '979, RE44,904, '465; voluntarily dismissed (Dkt. #15/#16), early Nov. 2025.
• CommWorks Solutions, LLC v. Marvell Technology, Inc. — W.D. Tex., 7:25-cv-00354, filed 8/18/2025; patents '465, RE44,904, '249; joint motion to stay for settlement and notice of voluntary dismissal, 10/29–10/31/2025.
• CommWorks Solutions, LLC v. Broadcom — C.D. Cal., 2:25-cv-02998 (SoC accused products).
• CommWorks Solutions, LLC v. Digi International Inc. — D. Minn., 0:26-cv-03949, filed Sept. 2026 (per PACER Monitor). (Note: this date is later than the task's stated "current date"; I report it as found in the source.)

In every CommWorks complaint inspected, the asserted patents are the Wi-Fi/802.11-lineage patents listed above — U.S. 7,289,456 is not among them.

---

D. Critical caveats before you rely on this negative

1. The reissue is the real risk. US 7,289,456's family includes US RE43,704 E1 (from application 12/608,732, priority 2009-10-29). A suit filed against the reissue would carry the RE43,704 number, and a number-specific search on "7,289,456" would miss it. Confirm separately whether RE43,704 has been asserted. (Do not confuse RE43,704 with RE44,904, which is a different reissue asserted by CommWorks on other patents.)
2. Absence-in-my-search ≠ absence-in-PACER. My queries returned no '456-specific case, but I could not exhaust PACER/CM-ECF docket text or the Darts-IP record in this pass. The controlling check is a full-text docket search on PACER/CourtListener and the Darts-IP family entry.
3. The patent is recorded as Ceased / expired 2024-09-20, which sharply reduces any remaining incentive to assert it — consistent with the absence of '456-specific litigation.

---

E. Recommended verification steps (to close the file definitively)

1. PACER / CourtListener full-text search on the literal strings 7,289,456 and 7289456, plus separate searches on RE43,704 / RE43704.
2. Darts-IP family 28674372 — open the family record to see which family member (if any) was actually litigated; the Google Patents flag is family-level and does not prove '456 was asserted.
3. USPTO PatentCenter "Litigation" / AO-120 tab for application 10/118,187 (the AO-120 report identifies patents asserted in filed actions).
4. If a demand letter or complaint cites '456, confirm whether the asserted claims are the original numbered claims or the reissued claims of RE43,704 — the single highest-risk identification error in this file.

Confidence: I am highly confident there is no known, confirmable litigation asserting U.S. Patent No. 7,289,456 based on the sources reached. I am not fully confident about (a) the reissue RE43,704's assertion history, or (b) PACER dockets outside my search coverage — both are flagged as open items rather than answered.

PTAB / AIA Trial Proceedings — U.S. Patent No. 7,289,456

Scope note on sourcing. The canonical list in the structured "PTAB proceedings on file" block (USPTO Open Data Portal ingest) contains zero AIA trial proceedings for this patent. I ran web searches to look for any proceeding the ODP had not yet indexed (PTAB petition PDFs, PTAB Trial Center, litigation/PG-claims aggregators, Federal Circuit dockets) and found none. Because the answer is a negative, I am being deliberately explicit about what I checked and what I could not check, rather than manufacturing proceeding numbers. Do not cite any IPR/PGR/CBM number for this patent without re-verifying against PTAB E2E or the ODP — none exists in my sources.

---

Proceedings overview

Total AIA trial proceedings on US 7,289,456: 0. Breakdown: 0 active, 0 with claims canceled, 0 with claims sustained, 0 settled, 0 institution-denied, 0 on appeal. The bottom line for a defendant is the mirror image of a "hardened patent": the patent is PTAB-untested — no claim has ever been construed, instituted, or canceled by the Board, and therefore no § 315(e)(2) estoppel has ever attached to anyone. The defensive posture is "clean slate, but also no free kill shot — you will have to build your own invalidity record from scratch," constrained by the fact that the patent is recorded as Ceased, adjusted expiration 2024-09-20, which makes a prospective IPR filing of limited practical value.

No proceedings to report

No proceeding entries are listed below because there are none on file. Instead, here is the auditable basis for that conclusion, plus the false positives I encountered and excluded.

What was checked

False positives I excluded (flagged so you don't chase them)

• US 6,725,456 (Bruno et al.) — appears in an IPR record as "the '456 was invented at world-renowned Bell Labs" and "the '456 Patent." This is a different patent (a QoS/API patent), not US 7,289,456. The shorthand "'456" is the trap here.
• "the '946 patent" — an IPR2024-01250 reference to a different patent ending in 946 (multi-user detector / legacy protocols). Unrelated.
• US 8,072,893, US 8,965,932, US 8,504,746, US 8,966,144, US 6,895,449, US 6,470,399 — all appeared adjacent to PTAB petitions in my searches but are unrelated patents; none is the Telcordia routing/provisioning patent.

Timing context that explains the absence

The '456 patent's enforcement-era appears to be 2004–2010, i.e., pre-AIA. One search surfaced Telcordia Technologies, Inc. v. Alcatel S.A. / Alcatel USA, Inc., Telcordia v. Lucent Technologies Inc., and Telcordia v. Cisco Systems, Inc. (D. Del. C.A. Nos. 04-874/875/876-GMS; and the Federal Circuit appeal at 612 F.3d 1365 (Fed. Cir. 2010)). AIA trials did not exist before 2012-09-16, so any validity challenge mounted during that litigation window could only have been an ex parte or inter partes reexamination — a different statutory animal outside this task's scope. I did not confirm which patents were asserted in those Delaware cases; do not assume '456 was among them on my say-so.

Reissue counterpart — the one thing to check before you rely on this page

The '456 record shows a reissue family member, USRE43704E1, with priority traced to application US12/608,732 (2009-10-29). It appears to be a reissue of this patent's application 10/118,187, but I could not verify that from a primary source in this pass, so treat it as unconfirmed. Two practical consequences:

1. A PTAB proceeding on the reissue would carry a different patent number (RE43,704), and a number-specific search on "7,289,456" would not catch it. If you are being asserted against the reissue (or the RE and the original together), re-run PTAB E2E and the ODP against RE43,704 — that is the gap in my check.
2. If the original claims were surrendered via reissue, then certain original '456 claims may no longer be enforceable, which is a statutory-disclaimer issue rather than a PTAB issue — but it will matter more to your case than anything on this page.

---

Strategic summary

Claim status: everything is UNTESTED. None of claims 1–28 (the full claim set) has been canceled, held patentable, or even instituted upon by the Board. There are no surviving-narrowed claims to quote because no FWD exists. Independent claims 1 and 5 (system claims), 9 and 11 (graph-building and path-determination method claims), 22 (a second path-determination method claim, truncated in the source text), plus dependents 2–4, 6–8, 10, 12–21 all remain as issued — subject only to whatever the Certificate of Correction / reissue record says, which you must verify independently.

Estoppel landscape: there is none. Because no proceeding ever reached a Final Written Decision, no petitioner, real party in interest, or privy is barred under 35 U.S.C. § 315(e)(2) from raising any § 102/§ 103 ground in a civil action. That cuts both ways for a defendant: (a) you are not boxed in by someone else's bad IPR — you can raise any prior-art ground you like in district court; but (b) there is no estoppel protecting you from a patent owner arguing claim scope, and no prior institution decision to point to as the Board's read on the claims. You also inherit no benefit from a prior petitioner's expert record.

Pattern signals: absent, not adverse. No repeat-petitioner pattern (there is no petitioner at all). No patent-owner appeal conduct at the PTAB, because there is nothing to appeal. No defensive aggregator (Unified Patents, RPX, etc.) appears anywhere in the '456 chain — searches for Unified Patents activity on this number returned nothing. Current owner CommWorks Solutions, LLC (acquired 2020 via Intellectual Ventures Assets 130 LLC; preceded by Nytell Software LLC, 2015) is an active and sophisticated litigant, but on a different patent family — the Wi-Fi/802.11 portfolio (e.g., US 7,027,465; RE44,904; 6,832,249; 7,177,285; 7,463,596; 7,911,979; 6,891,807; 9,554,304). The absence of any PTAB challenge to the '456 across the entire 2012–2024 window in which AIA trials existed, by an owner that clearly knows how to litigate, is itself a signal: this patent appears to have been commercially low-value for assertion.

---

Recommended next steps

1. Do the definitive PTAB check yourself, on the exact strings. Run patent-number searches on the PTAB Trial Center / E2E (https://ptacts.uspto.gov/ptacts/) and the USPTO ODP for "7,289,456", "7289456", and separately "RE43,704" / "RE43704". My search budget capped before I could exhaust the Unified Patents litigation portal and ODP queries directly, so the ODP block plus your own E2E pull is the controlling answer.
2. CourtListener full-text, for the record. Search https://www.courtlistener.com/?q=%227289456%22 and the literal 7289456, and a separate query for the reissue. Because there is no FWD and no FWD disposition to quote, there is no PTAB decision link to hand you — the negative is the deliverable.
3. If you are a defendant, plan around the absence of PTAB cover. With no § 315(e)(2) estoppel in play, your invalidity case lives entirely in district court (and the PTAB window is largely academic given the recorded 2024-09-20 adjusted expiration). Focus on (a) § 102/§ 103 art against claims 1, 5, 9, 11 and 22, charting against the "routing node = any ingress port interconnectable to any egress port" limitation that does the heavy lifting in every independent claim; and (b) § 112 support for the "partial network element" node concept, which is the broadest and least-supported term in the claim set.
4. Check the reissue before anything else. If the demand letter or complaint cites the '456, confirm whether the asserted claims are the original numbered claims or the reissued claims (RE43,704). Getting this wrong is the single highest-risk error in this file.
5. Verify the predecessor-litigation record. Pull the D. Del. complaints in C.A. Nos. 04-874/875/876-GMS (Telcordia v. Alcatel / Lucent / Cisco) and the Fed. Cir. appeal at 612 F.3d 1365 to see which patents were actually asserted. If '456 was asserted there, the old invalidity contentions and any inter partes reexamination history would be the most valuable prior-art roadmap available to you — and it is not indexed anywhere I could reach.

Confidence statement: I am highly confident there is no AIA trial proceeding on US 7,289,456, based on the authoritative ODP block plus corroborating searches. I am not confident about the reissue's proceeding history or about whether '456 was asserted in the 2004–2010 Telcordia litigation — both are flagged as open items rather than answered.

I'll research the assignment record for US 7,289,456 using the authoritative USPTO Assignment Center and cross-referencing sources.

Let me dig for the specific reel/frame records and the IV/CommWorks linkage.

Assignment & Ownership Analysis — US 7,289,456 B2

Critical sourcing caveat (read first): The USPTO Assignment Center abstract-of-title for this patent (which is the only source that exposes reel/frame numbers and the recorded correspondent) could not be retrieved in this session — the Assignment Center and its legacy mirror were not reachable through the search tooling I had. Accordingly, the timeline below is reconstructed from the Google Patents legal-events record supplied as authoritative source material for this patent. Google Patents lists the conveyance, assignor, assignee, and event dates but does not publish reel/frame numbers or the correspondent of record. I therefore mark every reel/frame and correspondent field as [not retrieved — verify at Assignment Center]. I will not invent reel/frame values.

Verification link: U.S. Patent Assignment Search — https://assignmentcenter.uspto.gov/ (search Patent No. 7289456, or Application 10/118,187).

There are recorded assignments for this patent (so I do not stop after this section), but the granular reel/frame layer is missing from the data I can currently cite.

---

Inventors

• All three inventors assigned their rights to Telcordia Technologies, Inc. by the recorded "ASSIGNMENT OF ASSIGNORS INTEREST" dated/recorded 2002-09-16 (Google Patents legal events; assigned to TELCORDIA TECHNOLOGIES, INC., assignors Ferrer, Gupta, Raheja). This is a routine employee-inventor → employer assignment executed within ~5 months of the 2002-04-08 filing, consistent with a standard obligation-to-assign.
• Unusual-pattern check: Not present. There is no record of any inventor departing to form a competing entity, and no inventor-initiated assignment. The three inventors appear only as assignors-to-employer; no inventor appears anywhere later in the chain. This does not fit the "all inventors leave within 12 months → fire-sale precursor" profile. The eventual monetization of this patent happened 7–8 years after filing, driven by corporate transactions at the assignee level, not by inventor behavior.
• Confidence note: Employer attribution is inferred from the original assignee and from Telcordia's known AT&T/Bellcore lineage; individual employment records are not public. I did not independently verify each inventor's job title.

---

Original assignee

Telcordia Technologies, Inc. (Piscataway, New Jersey).

• Lineage/status: Telcordia is the former Bellcore (Bell Communications Research), the R&D arm of the Regional Bell Operating Companies. SAIC acquired Bellcore in 1997 and rebranded it Telcordia Technologies. Telcordia was subsequently acquired by Ericsson in 2012. The interconnection/number-portability business was later spun/rebranded as iconectiv (circa 2017). So the original assignee is not an independent operating company today — it was acquired, then its relevant business rebranded.
• Primary line of business: Telecommunications network software, operations support systems (OSS), network configuration/management, and interconnection infrastructure — i.e., Telcordia was a telecom software and services vendor. This patent (network configuration management, route determination/provisioning) is squarely a Telcordia OSS product line patent.
• Did they ship a product embodying the claims? No product is named in the patent or in the records I can cite. The specification describes a "network configuration management system" / "routing manager" framework rather than a branded commercial product with a model number. I found no evidence of a specific shipping Telcordia product mapped to these claims, and I will not assert one. (Treat "shipped an embodying product" as unclear/not established.)
• Third-party artifact flag: A user-generated wiki page (wiki.golden.com) states 7,289,456 was "granted and assigned to iconectiv." This is a naming artifact, not a recorded assignment — iconectiv is a later business rebrand of a Telcordia unit, and no assignment to "iconectiv" appears anywhere in the recorded chain. Do not treat it as a transfer.

---

Assignment timeline

Chronological, from the Google Patents legal-events record. Reel/frame and correspondent: [not retrieved — Assignment Center only].

• 2002-04-08 (filed) / recorded 2002-04-08 — Reel [not retrieved]

  • Conveyance: Application filing (original applicant: Telcordia Technologies, Inc.)
  • Assignor: inventors (Gupta, Ferrer, Raheja)
  • Assignee: Telcordia Technologies, Inc.
  • Correspondent: [not retrieved]
  • Context: Initial filing; inventors still held legal title at filing pending the below assignment.

• 2002-09-16 (executed) / recorded 2002-09-16 — Reel [not retrieved]

  • Conveyance: Assignment of Assignors' Interest
  • Assignor: Ferrer, Richard S.; Gupta, Sanyogita; Raheja, Raj C. (individually)
  • Assignee: Telcordia Technologies, Inc.
  • Correspondent: [not retrieved]
  • Context: Routine employee-inventor → employer assignment; not a monetization event.

• 2005-04-05 (executed) / recorded 2005-04-05 — Reel [not retrieved]

  • Conveyance: Security Agreement
  • Assignor: Telcordia Technologies, Inc.
  • Assignee: JPMorgan Chase Bank, N.A. (as Administrative Agent)
  • Correspondent: [not retrieved]
  • Context: Securitization / collateral — Telcordia pledged its patent estate as loan collateral.

• 2007-07-06 (executed) / recorded 2007-07-06 — Reel [not retrieved]

  • Conveyance: Termination and Release of Security Interest
  • Assignor: JPMorgan Chase Bank, N.A. (as Administrative Agent)
  • Assignee: Telcordia Technologies, Inc.
  • Correspondent: [not retrieved]
  • Context: Release of the 2005 collateral lien (loan repaid/refinanced).

• 2009-03-17 (executed) / recorded 2009-03-17 — Reel [not retrieved]

  • Conveyance: Release of Security Interest
  • Assignor: Wilmington Trust Company
  • Assignee: Telcordia Technologies, Inc.
  • Correspondent: [not retrieved]
  • Context: Release of a separate security interest held by a different trustee — the second of two known liens against the estate, both cleared before the licensing spin-out.

• 2009-06-26 (executed) / recorded 2009-06-26 — Reel [not retrieved]

  • Conveyance: Assignment of Assignors' Interest
  • Assignor: Telcordia Technologies, Inc.
  • Assignee: Telcordia Licensing Company LLC
  • Correspondent: [not retrieved]
  • Context: Internal reorganization — Telcordia parks its patent estate in a dedicated licensing/holding LLC (a classic pre-monetization step; also aligns with the reissue filing below).

• 2009-10-29 — (event) Priority to US 12/608,732, issuing as US RE43,704 E1 (reissue of this family). Not an ownership transfer, but the reissue is a live family member — any subsequent assertion may name the reissue rather than the '456 patent, and the same ownership chain flows through it.

  • Correspondent: [not retrieved]
  • Context: Family continuation/reissue; not an ownership change.

• 2010-11-13 (executed) / recorded 2010-11-13 — Reel [not retrieved]

  • Conveyance: Assignment of Assignors' Interest
  • Assignor: Telcordia Licensing Company LLC
  • Assignee: TTI Inventions A LLC
  • Correspondent: [not retrieved]
  • Context: Transfer to a patent aggregator — "TTI Inventions A LLC" is one of a family of acquisition vehicles (TTI Inventions A/B/C/D) associated with the Intellectual Ventures-affiliated ecosystem that took in the Telcordia portfolio. This is the point at which the patent leaves operating-company hands permanently.

• 2015-12-31 (executed) / recorded 2015-12-31 — Reel [not retrieved]

  • Conveyance: Merger
  • Assignor: TTI Inventions A LLC
  • Assignee: Nytell Software LLC
  • Correspondent: [not retrieved]
  • Context: Internal holding-entity reorg — the aggregator vehicle folds into another non-operating holding entity (Nytell Software LLC), consistent with recurring renaming/reshuffling of the IV-style shell stack.

• 2020-01-03 (executed) / recorded 2020-01-03 — Reel [not retrieved]

  • Conveyance: Assignment of Assignors' Interest
  • Assignor: Intellectual Ventures Assets 130 LLC
  • Assignee: CommWorks Solutions, LLC
  • Correspondent: [not retrieved]
  • Context: Transfer to an entity that then asserts. Note the record's assignor is Intellectual Ventures Assets 130 LLC, which implies an intervening Nytell Software LLC → Intellectual Ventures Assets 130 LLC step that Google Patents does not surface as a discrete event. The chain Nytell (2015) → IV Assets 130 → CommWorks (2020) is a cascade through chained LLCs.

• 2020-11-05 (executed) / recorded 2020-11-05 — Reel [not retrieved]

  • Conveyance: License
  • Assignor: CommWorks Solutions, LLC
  • Assignee: Unwired Solutions, Inc.
  • Correspondent: [not retrieved]
  • Context: License (not an ownership transfer) — a right-to-use encumbrance recorded against the patent.

• 2021-02-04 (executed) / recorded 2021-02-04 — Reel [not retrieved]

  • Conveyance: Corrective Assignment (correct the assignee name previously recorded at Reel 054443 / Frame 0958 — reel/frame from the underlying corrected record, not the '456 abstract)
  • Assignor: CommWorks Solutions, LLC
  • Assignee: Unwired Broadband, Inc.
  • Correspondent: [not retrieved]
  • Context: Correction of the 2020 license's assignee name (Unwired Solutions → Unwired Broadband).

• 2022-02-16 (executed) / recorded 2022-02-16 — Reel [not retrieved]

  • Conveyance: Corrective Assignment (correct the nature of conveyance previously recorded at Reel 056981 / Frame 0631)
  • Assignor: CommWorks Solutions, LLC
  • Assignee: Unwired Broadband, Inc.
  • Correspondent: [not retrieved]
  • Context: Correction — the parties restated the character of the earlier conveyance. Two corrective filings in 12 months is a documentation-hygiene flag, not a new transfer.

• 2024-09-20 — Adjusted expiration; patent status Ceased / expired (per Google Patents legal status). Not an assignment. The assertion window is closed; term ended.

Cross-check flag (contradiction with the prior Litigation section — resolved, not a true conflict): The previously generated Litigation summary established that no suit naming 7,289,456 specifically could be confirmed, while the assignee's general campaign (CommWorks) is heavily documented. My ownership findings are consistent with that: the patent was transferred into an active assertion vehicle's portfolio in Jan 2020, but the record does not show this patent being asserted. The two sections are compatible; the transfer is proven, the assertion is not.

---

Timeline diagram

timeline
    title Ownership of US 7289456
    2002 : Filed by Telcordia Technologies
         : Inventors assign to Telcordia
    2005 : Security agreement to JPMorgan Chase
    2007 : JPMorgan releases security interest
    2009 : Wilmington Trust releases interest
         : Assigned to Telcordia Licensing LLC
    2010 : Assigned to TTI Inventions A LLC
    2015 : TTI Inventions A merger to Nytell
    2020 : Assigned to CommWorks Solutions LLC
         : License recorded to Unwired Solutions
    2021 : Corrective deed to Unwired Broadband
    2022 : Second corrective deed Unwired Broadband
    2024 : Patent term ends

---

NPE / troll-pattern signals

1. Shell-entity transfer — PRESENT.
   The patent leaves operating-company hands at the 2009-06-26 Telcordia → Telcordia Licensing Company LLC assignment and never returns to an operating company. It then passes to TTI Inventions A LLC (2010-11-13) and Nytell Software LLC (2015-12-31) — all licensing/holding vehicles, none of which is documented as shipping a product. The 2020-01-03 assignor is Intellectual Ventures Assets 130 LLC, another IP-holding vehicle. Caveat per instructions: the finding rests on the transaction chain + absence of any product, not on the "LLC" naming alone.

2. Known asserter in the chain — PRESENT.
   CommWorks Solutions, LLC (current assignee, per the 2020-01-03 record and Google Patents "Current Assignee") is a serial plaintiff — it has sued cable/telco defendants on networking and Wi-Fi patents in W.D. Tex., E.D. Tex., S.D.N.Y., and D. Del. (see theipcrew case roundup, Sept. 17, 2020; Mondaq/RPX coverage, June 10, 2020). Its patents include US 6,832,249; 6,891,807; 7,027,465; 7,177,285; 7,463,596; 7,911,979; RE44,904 — a portfolio it received out of the Intellectual Ventures divestiture wave. Unified Patents challenged CommWorks patents (e.g., IPR2021-01297 on US 8,923,846), confirming it as a recognized high-frequency patent owner. Ancestors Nytell Software LLC and TTI Inventions A LLC sit in the Intellectual Ventures ecosystem of holding entities. Not a comparison against the specific named lists in the prompt (Acacia, Marathon, Wi-LAN, etc.) — none of those appear here; the match is to the IV/CommWorks/IP-Investments cluster surfaced by RPX and Unified Patents.

3. Repeat correspondent across the chain — UNCLEAR (cannot be scored).
   Correspondent-of-record data is exactly what the Assignment Center exposes and what I could not retrieve. I will not guess. Action item: pull the abstract of title for 10/118,187 and list the correspondent on each of the eight recorded instruments (2002, 2005, 2007, 2009, 2010, 2015, 2020, 2020/2021/2022). The test is recurrence — e.g., whether the same attorney/agent recorded the Nytell, IV Assets 130, and CommWorks links. A single appearance is not a finding.

4. Cascading transfers — PRESENT.
   Three ownership hops in <10 years through non-operating entities: Telcordia Licensing (2009) → TTI Inventions A (2010) → Nytell (2015) → [IV Assets 130, intervening, un-datelined in the event feed] → CommWorks (2020-01-03). The 2020 and 2021–2022 entries add a license plus two corrective filings against the same patent. The 2015 → 2020 sequence — merger into Nytell, then reappearance of Intellectual Ventures Assets 130 LLC as assignor — is the clearest cascade: the assigning entity in 2020 is not the assignee of record five years earlier, proving at least one intermediate transfer in the shell stack.

5. Pre-litigation transfer — PRESENT (as to the assignee; UNCLEAR as to this patent).
   The transfer to CommWorks Solutions, LLC on 2020-01-03 lands the patent in a plaintiff that began filing its networking-assertion campaign in mid-2020 (Mondaq noted CommWorks opening "networking litigation" in June 2020; theipcrew logged S.D.N.Y. complaints in Sept. 2020). That is within ~6 months — the classic pre-assertion placement. However, the prior Litigation section could not tie any suit to the '456 number specifically, so the "this patent was transferred in order to be asserted" inference is strong as to portfolio strategy but unproven as to this document.

6. Bankruptcy fire-sale — NOT PRESENT.
   No Chapter 7/11 appears in the record. Telcordia was solvent and was acquired by Ericsson (2012); the 2009–2010 licensing entity and aggregator transfers are voluntary monetization, not a distress sale. (Contrast the classic Kodak/Nortel/Polaroid pattern — absent here.)

7. Privateering — PRESENT (moderate).
   The chain runs operating company (Telcordia) → aggregator (TTI Inventions A) → Intellectual Ventures-linked vehicle → CommWorks. Litigation filings have alleged that IV retained a security interest and a revenue backend on the divested portfolios and coordinated the assertion campaigns through IP-Investments-controlled LLCs — the Altice USA declaratory-judgment filings against CommWorks, DataCloud, and DigiMedia (reported in IPWatchdog, Sept. 22, 2021: allegations of "a broader, coordinated patent assertion campaign driven by Brainbox and executed through" the LLCs). That is the privateering/monetization-backend footprint: the original (or intervening) holder supplies the assets and shares the upside while the shell fronts the litigation. I flag it as an allegation in litigation, cited to the filing coverage, not as an adjudicated fact.

8. Defensive aggregator (anti-NPE) — NOT PRESENT.
   The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. It terminates at an assertion entity (CommWorks), i.e., the inverse of neutralization. Unified Patents appears in this history only as an adversary (IPR petitioner against CommWorks), not as an owner.

---

Verdict

NPE — high confidence.

The recorded chain shows the patent passing out of an operating telecom-software vendor's hands into a dedicated licensing LLC (Telcordia Licensing, 2009-06-26), then into aggregator/holding vehicles (TTI Inventions A LLC, 2010-11-13; Nytell Software LLC by merger, 2015-12-31), then via an Intellectual Ventures vehicle (Intellectual Ventures Assets 130 LLC, assignor on 2020-01-03) to CommWorks Solutions, LLC — a documented serial plaintiff whose campaign began within ~6 months of that transfer. That is four corroborating signals (shell-entity transfer, known asserter, cascading transfers, pre-litigation transfer), well above the two-strong-signal threshold for high confidence. The one honest limitation, carried over from the prior Litigation section, is that no suit naming 7,289,456 itself has been confirmed, so the placement is proven at the assignment level while the actual assertion of this patent remains unverified; and the repeat-correspondent test could not be scored because reel/frame + correspondent data was not retrievable in this session.

To finalize (do these next): (1) pull the abstract of title at https://assignmentcenter.uspto.gov/ for App. 10/118,187 to capture the eight reel/frames and correspondents; (2) confirm the intervening Nytell → Intellectual Ventures Assets 130 LLC instrument and its date; (3) check whether US RE43,704 E1 (a separate family member with its own chain) has been asserted where the '456 has not.

I'll search for the USPTO record and cited prior art for US 7,289,456.

I found the examiner's cited references list. Let me get the complete citations list from the patent document itself.

Let me get the authoritative front-page references list from the patent document itself.

Prior-Art Analysis — U.S. Patent No. 7,289,456 B2

Scope note / flag first: This section builds on the earlier bibliographic, claim-mapping, and litigation sections and does not repeat them. One housekeeping contradiction should be flagged: the earlier sections were generated with the header date 2026‑09‑27; this task header states April 26, 2026. I treat the patent record as unchanged either way, but the two "current dates" are inconsistent across the analysis.

---

1. USPTO identification of the exact patent (no look‑alikes)

The search target resolved to exactly one document, and the identifiers all cross‑check:

Sources: https://patents.google.com/patent/US7289456/en ; EBSCO/ProQuest structured patent record edspgr.07289456 surfaced via https://library.cnu.ac.kr/eds/detail/edspgr_edspgr.07289456

Deliberate exclusions (numbers that end similarly but are not this patent): US 4,456,728 (Garuti, 1984); US 7,027,465 (“Determining and provisioning paths in a network,” related Telcordia family member, a different document); US 7,881,229 (citing ’456 forward, not prior art); US RE43,704 (reissue line in the same family, not a prior-art publication). I did not substitute any of these for 7,289,456.

Critical sourcing gap — state plainly: The authoritative full text of ’456 that you supplied (and the Google Patents page as fetched) does not include the printed front-page (56) “References Cited” section, the FOREIGN PATENT DOCUMENTS list, or the OTHER PUBLICATIONS list. Google Patents renders those in a separate "Citations" block that was not captured in the retrieved text. Accordingly, my prior-art list below rests on a secondary structured record, not on the patent's own printed front page. That is a real evidentiary limitation, and I flag it rather than paper it over.

---

2. The cited references I could actually verify

The only structured source that reproduced a “Patent References Cited” field for this exact patent number was the EBSCO/ProQuest patent record for edspgr.07289456 (via the CNU library link above). It records the following under Patent References Cited:

Bottom line on descriptions: I could not retrieve the title, abstract, or claims of any of these five publications within the search budget. I will therefore not supply invented subject‑matter descriptions for them. Where I can offer a grounded observation, it is labeled as inference and explicitly not relied upon.

Two grounded items:

• Kodialam (item 1): Murali Kodialam was a Bell Labs (Lucent) researcher working on routing/MPLS traffic engineering with bandwidth guarantees. That is an inference from the inventor’s known field, not verified from the document itself. I would not assert it as fact.
• Numbering discrepancy — flagged, not auto-corrected: A separate result shows a different Kodialam publication, US 2002/0067693 A1 (June 6, 2002), appearing in the “References Cited” list of US 7,881,229 (https://patents.justia.com/patent/[7881229](/patent/7881229)). Whether the ’456 record’s “2002/0018264” and this “2002/0067693” are two distinct Kodialam documents or a record error is unresolved. Per the operating rules I am treating the EDS‑recorded string literally rather than correcting it.

---

3. Foreign patent documents and non‑patent literature

Not retrieved. I could not recover any FOREIGN PATENT DOCUMENTS or OTHER PUBLICATIONS entries for ’456 from the sources reached. I state this as a gap, not as an absence — the printed front page of ’456 may well list WO/EP/JP items and NPL (e.g., Telcordia/Bellcore Generic Requirements, ATM Forum, or IETF documents consistent with the specification's ATM/Frame Relay/DWDM framing). Until the front page is read directly, any list I gave would be speculation.

---

4. § 102 analysis — framework and the date problem

4.1 The controlling date

• Application filing / priority: 2002‑04‑08 (no earlier priority claimed on the face of the record).
• Therefore art is § 102(a)/(b) only if published or patented before 2002‑04‑08, and § 102(e) only if a U.S. application/patent has an effective U.S. filing date before 2002‑04‑08.

4.2 A date problem affects three of the five recorded references

Items 3 (2003/0135304, Jul. 2003), 4 (2005/0089027, Apr. 2005), and 5 (2005/0197993, Sep. 2005) have publication dates after the ’456 filing date. On their face they are not § 102(a)/(b) prior art. They can only matter if:

• their underlying U.S. applications were filed before 2002‑04‑08 (§ 102(e)), or
• they are family members of an earlier-filed application, or
• they are cited merely as background/IDS items, not as applied art.

This matters because a five‑year prosecution window (2002→2007) is a plausible reason late-published items appear on the front page. I could not verify any of these three references' filing dates. Until those dates are confirmed, they should be treated as possibly non-prior-art citations.

4.3 Which claims those references could reach (conditional, not asserted)

’456's independent claims fall into two families (see the earlier claim-mapping section, not repeated here): the system claims 1 and 5 and the method claims 9, 11, and 22.

The load‑bearing point: The distinctive limitation in every independent claim is the “routing node” abstraction — a node representing a partial element, a single element, or a group of elements, where any combination of that node’s interconnectable edge ports can be interconnected. That is what distinguishes ’456 over the port‑per‑node modeling the specification identifies as prior practice. None of the references I could verify is confirmed to disclose that abstraction, so on the evidence I have, I cannot responsibly assert that any of the five references anticipates claims 1, 5, or 9; a § 102 challenge on those claims would most plausibly have to come from the unretrieved foreign/NPL art or from a reference I have not yet identified.

4.4 Dependent‑claim observations (grounded in the ’456 text, not in the references)

Because they are narrower, the dependent claims are where a reference is most likely to bite:

• Claims 3 and 4 (element adapter; per‑cross‑connection status database with re‑provisioning of only unprovisioned cross‑connects) carve out the specification’s provisioning/rollback machinery. Any pre‑2002 network‑configuration/management system performing partial‑failure retry could be § 102 art against these — but I have not identified such a reference in the ’456 citation list.
• Claim 8 / 21 (secondary paths computed as shortest paths to the destination’s neighboring nodes) is a specific algorithmic recitation that maps naturally onto standard k‑shortest‑path / Dijkstra literature, which the ’456 specification itself acknowledges (Dijkstra). A Dijkstra/k‑shortest‑path publication pre‑dating 2002 could be § 102(b) art against claim 8/21 — again, not confirmed on this record.

---

5. Forward citations (context only — NOT prior art)

Separately, US 7,881,229 (“Systems and methods for forming an adjacency graph for exchanging network routing data”) lists US 7,289,456 — Gupta et al., Oct. 30, 2007 in its own “References Cited” (https://patents.justia.com/patent/7881229). That is a citation of ’456 by a later patent, i.e., evidence of the field, not § 102 art against ’456. I include it only so it is not mistaken for a ’456 reference.

---

6. What I am explicitly NOT claiming (uncertainty ledger)

1. The full (56) list is unknown to me. I have five U.S. publication numbers from one secondary record. The patent’s printed front page may contain issued U.S. patents, foreign documents, and NPL that I did not see.
2. No verified descriptions for any of the five references — I declined to invent them.
3. No verified examiner rejections. “References Cited” ≠ “prior art applied.” I cannot say which reference the examiner used against which claim; that requires the file wrapper (PTAB/PatentCenter IFW, or the 90/‑series/reexam file if one exists).
4. The three post‑2002 publications (items 3–5) are date‑problematic and may not be § 102 art at all.
5. No § 102(e) analysis is possible without each reference’s effective U.S. filing date.
6. RE43,704 is a same‑family reissue, not prior art to ’456; it must not be cited as anticipating art. (Consistent with the earlier sections’ warning not to conflate RE43,704 with RE44,904.)

---

7. To close the gaps definitively (recommended, concrete)

1. Read the ’456 front page directly — pull the grant PDF (patentimages.storage.googleapis.com/.../US7289456.pdf) or the USPTO PatentCenter “References Cited” / “Foreign References” / “Other References” tabs. That yields the authoritative (56) list.
2. Open the file wrapper (IFW) for application 10/118,187 to see the examiner’s actual § 102/§ 103 rejections and which claims each reference was mapped to — this is the only way to answer “which claim(s) it potentially anticipates” as the examiner saw it.
3. Confirm each reference’s effective filing date for items 3–5 to test § 102(e).
4. Number‑specific art search on the routing‑node aggregation concept (network element aggregation / abstract cross‑connect node modeling, ATM/Frame Relay/DWDM network configuration management, ~1995–2002), since the cited five do not appear to reach claims 1/5/9 on the verified record.

If you authorize another search round (or supply the grant PDF / IFW), I can complete the per‑reference table with verified titles, filing dates, and examiner‑specific claim mappings.

I'll research the prior art associated with US 7,289,456 before analyzing obviousness.

Let me pull the actual cited prior-art references listed on the patent's face.

Let me try to retrieve the front-page references and any reexamination/prior-art record specific to this patent.

Obviousness Analysis — US 7,289,456 B2 under 35 U.S.C. § 103

0. Scope, sources, and an upfront limitation

Prior-art retrieval note (please read before relying on anything below). The task asks me to use "the results from the Prior Art section of this page." The authoritative page text supplied to me contains only these prior-art fields for US 7,289,456:

• Prior art keywords: "network, routing, node, path, elements"
• Prior art date: 2002-04-08
• Family has litigation flag; legal status: ceased / adjusted expiration 2024-09-20

The fetched page text does not reproduce the enumerated "References Cited / Cited By" listing (the front-page U.S. patent documents and non-patent literature), and my targeted attempts to retrieve that listing directly (Google Patents citation list; the pre-grant publication US 2003/0189919 A1; FreePatentsOnline; Justia) returned the specification and claims but not the face-of-the-patent reference numbers. I therefore cannot truthfully present the specific references the examiner cited against this patent, and I will not invent reference numbers to fill the gap.

What I can do rigorously — and what follows — is:

1. Anchor the § 103 analysis on the admitted prior art inside the patent's own Background/FIG. 1 (which is part of the "prior art" of record and is citable as an admission);
2. Layer in well-known, pre-April-2002 technical art that a challenger would actually rely on, each explicitly flagged as general technical knowledge rather than a verified face citation; and
3. Give the reference combinations and motivations the question asks for, with an honest statement of where each combination is strong and where it is exposed.

Confidence labels used below: [A] verified from the supplied patent text or a retrieved source; [B] high-confidence general technical knowledge (existence and substance), not verified as a citation on this patent's face; [C] low confidence / cannot verify.

---

1. Legal framework and level of ordinary skill

Framework. Under Graham v. John Deere Co., 383 U.S. 1 (1966), obviousness turns on (i) the scope and content of the prior art, (ii) the differences between the prior art and the claims, (iii) the level of ordinary skill, and (iv) secondary considerations. Under KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), a combination is obvious where the elements are arranged "according to known methods" to yield "predictable results," and the motivation may come from "the design incentives and other market forces," "the background knowledge, creativity, and common sense of the person of ordinary skill," or the fact that "a finite number of identified, predictable solutions" existed (the "obvious to try" doctrine). Where a claim recites aggregation/abstraction of data at a chosen level of detail, the § 103 inquiry is essentially whether the claimed abstraction was a predictable design choice among a small set of known alternatives.

PHOSITA [B]. A person with a Bachelor's degree in electrical engineering, computer science, or telecommunications (or equivalent) and roughly 2–4 years of experience in telecommunications network management / operations support systems (OSS), with working familiarity with: ATM and Frame Relay provisioning (VPC/VCC, VPI/VCI, DLCI); SONET/SDH and DCS; TMN-style NMS/EMS hierarchy; graph-based routing (Dijkstra shortest-path); and network inventory/configuration systems. The patent's own specification presumes exactly this background (it treats NMS/EMS behavior, virtual trunks, VPI/VCI/DLCI, and Dijkstra as known tools).

---

2. Decomposing the claims into their technical concepts

Independent claims are 1, 5, 9, 11, and 22; claims 22–28 are truncated in the source text and I cannot state their full scope [stated in the prior section as a caution, still true].

The only genuinely distinguishing technical idea in the patent relative to the admitted background is C2 — i.e., where the graph node is drawn (coarse-grained "routing node" = any-to-any cross-connect over a set of ports/elements) — plus the derivative propositions C3/C4/C6 that follow from that choice. Everything else (inventory subsystem, routing engine, adapters, status DB, multi-path) is conventional OSS plumbing that the specification treats as known.

---

3. Candidate prior art

3.1 Admitted prior art on the face of the patent (strongest, because it is the applicant's own statement) [A]

From the supplied Background/FIG. 1 text:

• A1 — Port-as-node modeling. "prior systems model a network by representing every port of every network element as a node of a graph and by maintaining a representation of the physical links that interconnect these ports as links that interconnect the nodes of the graph." → teaches C1 (graph), C3 (physical links as graph links).
• A2 — Separate services view for virtual trunks. "these systems separately maintain a services view of the network, which view is used to maintain representations of the established virtual trunks within the network." → teaches that modeling established virtual trunks in a second (service-layer) graph is old; the step to putting them in the same graph as "routing links" is an integration choice.
• A3 — NMS does intra-domain path computation + provisioning. "Given two edge ports 130 and 132, the NMS can determine a set of links and network element cross-connects to interconnect the edge ports and can subsequently provision the network elements to realize this interconnection." → This is a direct admission that a set of NMS-managed elements behaves as an any-port-to-any-port cross-connect — i.e., it already has the C2 property. The patent's own "cloud model" (FIG. 3) merely names that admitted fact.
• A4 — Hierarchical control (NMS / EMS / direct element control) in FIG. 1 → teaches the management-entity mapping underlying C4 and the adapter layer of C5.

Why A1–A4 matter: the applicant expressly conceded that the prior NCM systems (a) built graphs, (b) modeled links as graph links, (c) modeled virtual trunks separately, and (d) relied on NMSs that already provided any-edge-port-to-any-edge-port connectivity. The delta to the claims is therefore granularity of the node, not new functionality.

3.2 Well-known corroborating art a challenger would combine [B]

Caution on "specific numbers." I did not verify that P1–P10 appear on this patent's face, and I am not asserting that the examiner cited them. They are the art a challenger would use. If the previously generated "Prior Art" section did list specific references, my analysis should be re-run against that list; the combinations below are built to accept substitution of the actual cited references without changing the reasoning.

---

4. Combination-by-combination § 103 analysis

Combination I — Claim 1 (system: inventory subsystem + routing engine + service activation; routing-node abstraction)

Primary: A1/A3/A4 (the admitted NCM system of FIG. 1). Teaches C1 and the existence of an inventory/graph layer, a path-determination function, and NMS-provided any-edge-port-to-any-edge-port connectivity + provisioning.

Secondary: P1 (PNNI logical group node) and/or P3 (TMN subnetwork abstraction).

The difference between A1 and claim 1 is the node definition: A1 draws a node at each port; claim 1 draws a node at a partial element / element / group of elements having the interconnectable-edge-ports property.

Motivation (KSR):

1. Art-recognized problem, stated by the applicant itself: the specification complains that port-as-node models produce "large and complex graphs that create performance and scalability issues." P1/P3/P4 address exactly that known problem with exactly that known remedy — aggregation of a connected domain into one node. The problem and the solution were both known; only the application to this context was new.
2. The abstraction is dictated by the equipment's own capability. A3 admits the NMS already interconnects any two edge ports. If a device behaves as an any-to-any cross-connect, modeling it as a single cross-connect node is the natural (indeed, the faithful) representation. KSR: arranging known elements per a known function yields a predictable result.
3. Predictable result. Collapsing a subgraph into one node predictably shrinks the graph and speeds Dijkstra traversal without changing the computed end-to-end reachability — a result a PHOSITA would expect with high confidence.
4. Finite set of identified solutions. The level at which to draw the node (port / chassis / element / management-domain) is a small, enumerable design space; the specification itself enumerates it as four "models" (cloud, network-element, chassis-restricted, daisy-chain).

Conclusion (claim 1): Strong prima facie obviousness. The claim recites the same architecture as the admitted prior art and changes only the abstraction level of a graph node — a change the art (P1/P3) applied to the same problem for the same predictable benefit.

Dependent claims 2–4:

• 2 (virtual trunk as a routing link): A2 admits virtual trunks were already modeled (in a separate services view); merging that representation into the routing graph as a link is an integration/design choice, reinforced by P9 (LSP-as-link) and P2 (trail-as-link). Obvious.
• 3 (element adapter): A4 (NMS/EMS/direct-control hierarchy) + P3; adapter patterns are routine engineering; the patent itself calls them "a specific adapter for each type of NMS, EMS, and network element." Obvious.
• 4 (cross-connection status DB enabling re-provisioning): P10 (per-item provisioning state / idempotent retry) — conventional OSS. Obvious.

---

Combination II — Claim 5 (system: initial + secondary paths, choose preferred)

Primary: Combination I (to reach the claimed system and node abstraction).
Secondary: P6 (Yen k-shortest paths) + P4 (ECMP / load balancing) + P7 (PSTN alternate routing).

The difference is C6: the routing engine, when invoked, returns an initial path and one or more secondary paths, and the service activation system chooses a preferred path.

Motivation:

• Fallback: P7 establishes, decades earlier, that provisioning path selection should compute alternates so that a blocked/failed primary route can be bypassed. The '456 specification concedes this exact motivation: alternate paths are used "in the event a preferred path ... cannot be established."
• Load balancing: P4 (ECMP) and QoS-routing literature make multi-path selection for load balancing and bandwidth the standard reason to compute multiple paths — matching claim 7 and the specification's stated function.
• Implementation is off-the-shelf: P6 supplies the algorithm (including the "spur to neighbors" construction that claim 21 recites), so there is no new technique to discover; the claim merely routes the engine's output into the activation system.

Claims 6–8:

• 6 (fall back to another path if preferred fails): directly taught by P7. Obvious.
• 7 (bandwidth considered): P8. Obvious.
• 8 (secondary paths = shortest paths to the destination's neighboring nodes): this is the known Yen spur-path construction (P6). Obvious; arguably a straightforward expectation from choosing k-shortest paths at all.

Conclusion (claim 5 and 6–8): Strong. The multi-path feature is the classic reliability/load-balancing feature of P7/P4, implemented with the textbook k-shortest-path algorithm P6.

---

Combination III — Claim 9 (method of creating the graph via routing-model classification)

Primary: A1 + A4.
Secondary: P1/P3 (management-domain aggregation) + P10-type data-modeling practice (a lookup table mapping equipment type/manufacturer → model class, and bookkeeping to avoid duplicate node creation).

The differences are (a) obtaining a "routing model" that "indicates how ports ... can be interconnected among themselves and other network elements," (b) conditionally grouping the element with others into one routing node, and (c) conditionally creating one or several nodes.

Motivation / why obvious:

• The classification step is just reading the device's known connectivity capability — precisely the capability A3 admits the NMS already exposes, and the capability the specification attributes to specific commercial gear (Lucent CBX 500 → cloud; Alcatel 1000ADS → network element; DSC Litespan DSLAM → daisy-chain). A rule/table keyed on vendor + product is routine data modeling.
• The conditional branches (does a node already exist for this management domain? create one or many?) are ordinary record bookkeeping for maintaining a graph when equipment is added — the kind of housekeeping described in the specification as a list of database insert/search rules, with no new technical effect.
• The one-node-per-chassis vs. several-nodes distinction (also claim 16) is dictated by whether cross-connect capability is confined to a chassis — again a direct read of the hardware's known behavior.

Conclusion (claim 9 + 10): Obvious. Claim 9 reads as an automated implementation of the classification insight of Combination I; its conditional logic is standard inventory bookkeeping.

---

Combination IV — Claim 11 (method of determining a path) and dependent 12–21

Primary: A1 + Combination I (routing nodes; physical links as routing links).
Secondary: P2/P9 (virtual connection as link) for claim 12/18; P1/P3 for claims 13–15; hardware facts (chassis confinement) for claim 16; adapter/OSS practice for claims 17–18; P6/P7/P4/P8 for claims 19–21.

Claim 11 is essentially the method mirror of claim 1 minus the service-activation limitation; claims 19–21 are the method mirror of claims 5–8. The same reasoning and the same motivations apply, so claim 11 is obvious for the reasons given for Combination I, and claims 19–21 for the reasons given for Combination II.

• 13 (common management entity → one node): A3/A4 + P3. Obvious.
• 14 (multi-chassis, interconnected → one node): A3's any-to-any admission plus the known fact that a multi-chassis switch cross-connects across chassis. Obvious.
• 15 (daisy-chained elements → one node): The daisy-chain case is the weakest limb of this combination (see § 5). It is supported by the admitted premise that a parent chassis exposes all ingress ports and all egress ports and that the EMS "collectively manages" the chain — which is a functional-equivalence argument for aggregation, but depends on how clearly the art teaches the parent/child restriction.
• 16 (independent chassis → a node per chassis): Direct read of the hardware's capabilities; obvious.
• 17–18 (derive cross-connections; model provisioned trunk as a link): A3/A4 + P9. Obvious.

---

Combination V — Claim 22 (second independent method claim)

⚠️ The claim text I have truncates at "determining from the determined set of routing nodes and routing links a set of network …" Therefore I can analyze only what is visible: claim 22 appears to repeat claim 11's modeling steps and add the derivation of a set of cross-connections. To the extent claim 22 = claim 11 + cross-connection derivation, it is obvious for Combination IV + C5 (A3/A4). I cannot analyze claims 23–28 because their text is not in the source I was given.

---

5. Where the § 103 case is weakest (candor section)

1. No verified reference list. The single biggest weakness of this analysis (not of a real invalidity contention) is that I could not retrieve the enumerated prior art. Every combination above is constructible in principle, but a real petition must cite the actual documents with pinpoint support.
2. The "any interconnectable edge ports" property (C2). PNNI logical group nodes aggregate topology but do not guarantee any-to-any connectivity within a peer group (PNNI permits restricted connectivity). A patentee could argue that the claims require full any-port-to-any-port behavior per node, which generic aggregation art does not teach. Counter: A3 (the applicant's own admission) that an NMS interconnects any two edge ports supplies exactly this property for the cloud model, so the gap narrows to the non-cloud models.
3. Claim 15 (daisy-chain → one node). The parent/child-port restriction is idiosyncratic; aggregation is justified only if the EMS hides the chain. A patentee may argue non-obviousness here; a challenger would need art or reasoning tying daisy-chained DSLAM/hierarchy equipment to single-node abstraction.
4. Claim 22–28 scope unknown. Cannot assess.
5. Reissue caveat. The patent family includes US RE43,704 E1 (separate document, from application 12/608,732). A § 103 conclusion must be run against the claims as they stand in the document being challenged; if RE43,704 contains amended or narrowed claims, this analysis does not automatically carry over. Beware the identifier trap noted in the earlier section: RE43,704 ≠ RE44,904 (the latter is a different reissue asserted by CommWorks on other patents).
6. Do not infer validity from absence of IPR. No IPR/PGR/CBM for 7,289,456 surfaced in my searches, but absence of a challenge is not evidence of non-obviousness, and the patent is recorded as ceased/expired 2024-09-20, which reduces the incentive to challenge.

---

6. Summary table of combinations

---

7. Bottom line

On the record I can actually verify, US 7,289,456 is exposed to a strong § 103 challenge focused on a single insight: that the graph node should be drawn at the level of an element or a group of elements (a "routing node" with any-to-any interconnectable edge ports) rather than at each individual port. That insight is (a) admitted by the applicant to be no more than a re-description of what an NMS already does (A3), and (b) squarely taught as a solution to the very scalability problem the specification recites, by aggregation/hierarchy art like PNNI logical group nodes and TMN subnetwork abstraction (P1/P3), with IP-area summarization (P4) as further corroboration. The remaining claim features (virtual-trunk-as-link, adapters, provisioning-state DB, multi-path/fallback/bandwidth selection) are conventional OSS and classic alternate-routing/k-shortest-path techniques (P6–P10), and a PHOSITA had every reason to combine them.

Strongest claims to attack: 1, 5, 9, 11 (and their dependents 2–4, 6–8, 12–14, 16–21).
Weakest claims to attack: 15 (daisy-chain aggregation), and I cannot assess 22–28 because the source text truncates them.

Caveats that must accompany any formal use of this: (i) I could not retrieve the patent's enumerated "References Cited," so the specific references above are general-knowledge candidates, not verified face citations; (ii) the claims in the related reissue US RE43,704 E1 must be analyzed separately; and (iii) the earlier-noted third-party claim that this patent was assigned to "iconectiv" remains uncorroborated and conflicts with the recorded Telcordia → Telcordia Licensing → TTI Inventions A → Nytell → CommWorks chain — I continue not to rely on it.