US 7289456

I'll search for authoritative information on US 7289456 and any CAFC/litigation activity.

Let me search for litigation history and the reissue family member.

Let me verify the reissue relationships and check for any CAFC appeals involving this patent number.

Bottom line

I could confirm US 7,289,456 B2 from the authoritative full patent text, but I found no CAFC 2026 docket, appeal, or PTAB proceeding naming U.S. Patent No. 7,289,456. The patent is recorded as Ceased / expired 2024‑09‑20, and its recorded enforcement activity (through assignee CommWorks Solutions) appears in district courts, not at the Federal Circuit. Details, and the identifiers I could not verify, are flagged below.

Bibliographic summary — US 7,289,456 B2

Source: https://patents.google.com/patent/US7289456/en

Abstract (verbatim)

"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."

Plain-language overview of the independent claims

Claim 1 — System for provisioning a path (graph-based modeling).
A system with three 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 and, from the returned path plus the network model, derives the set of network-element cross-connections needed to stand up a virtual connection over that path. The core limitation is what a node means: links of the graph represent network links, and each node represents a partial network element, a single network element, or a group of network elements, where the node has edge ports and any combination of those edge ports that are capable of being interconnected can be interconnected. (This is the "routing node" abstraction — a modeled entity behaves as an abstract cross-connect.)

Claim 5 — System with primary + alternative path selection.
Same system architecture as claim 1 (inventory subsystem, routing engine, service activation system, and the same node/link definitions), but adds that the routing engine, when invoked, returns an initial path plus one or more secondary paths; the service activation system picks a preferred path from among them and determines the cross-connections to establish the virtual connection over the preferred path. (Claims 6–8 add fallback to another path if the preferred one fails, bandwidth-based path choice, and computation of secondary paths via the destination node's neighboring nodes.)

Claim 9 — Method of creating the routing graph.
A method for building a graph used for network routing:

1. Determine the routing model for a network element — i.e., how its ports can be interconnected among themselves and to other network elements.
2. Based on that model, decide whether the element should be grouped with other elements and represented collectively as one routing node.
3. If grouped: check whether a routing node already exists for that group; if not, decide (from the element and its model) whether one should be created.
4. If not grouped: decide from the model whether the element should be one routing node or several, and create accordingly.
5. Represent each network link as a routing link, and associate each routing link with the two routing nodes representing the two interconnected network elements — thereby creating the graph.

Claim 11 — Method of determining a path.
A method for finding a path between points: model the network elements as routing nodes (each representing a partial element, a single element, or a set of elements, with the "any interconnectable edge ports can be interconnected" property); model each physical link as a routing link between routing nodes; and determine the path as a set of routing nodes and routing links interconnecting the endpoints. (Claim 12 adds modeling virtual connections as routing links; claims 13–16 recite the specific modeling scenarios — common management entity, multi-chassis element as one node, daisy-chained elements as one node, and independent chassis as separate nodes; claims 17–18 add deriving cross-connections and modeling the provisioned virtual trunk as a routing link; claims 19–21 add the secondary-path/preferred-path and bandwidth features.)

Claim 22 — Method of determining a path (second, related independent claim).
Recites the same modeling steps as claim 11 (elements → routing nodes with the interconnectable-edge-port property; physical links → routing links; path determined as a set of routing nodes and routing links) and then adds determining, from that set, a set of network element cross-connections. ⚠️ Nota bene: the text I retrieved truncates claim 22 mid-sentence ("determining from the determined set of routing nodes and routing links a set of network …"), so I cannot authoritatively state the full scope of claim 22 or of claims 23–28, which are not reproduced in the source I have. Treat my description of claim 22 as partial.

Docket / litigation status

What I found:

• Google Patents flags the family as having litigation and links to a Darts‑IP family record (family=28674372). That is a family-level flag, not proof that 7,289,456 itself was asserted.
• Public district-court activity in this patent's assignee lineage is tied to CommWorks Solutions, LLC (a Brainbox Innovations/Intellectual Ventures-lineage NPE). Reported CommWorks cases include CommWorks v. Extreme Networks (W.D. Tex. 6:23‑cv‑00835), CommWorks v. Charter Communications (6:22‑cv‑00156), CommWorks v. Consolidated Communications (E.D. Tex. 2:20‑cv‑00159), CommWorks v. Texas Instruments (E.D. Tex. 2:25‑cv‑00439), CommWorks v. Marvell Technology (W.D. Tex. 7:25‑cv‑00354), and CommWorks v. STMicroelectronics (7:25‑cv‑00363).
• Critically, in the CommWorks complaints I could inspect, the asserted patents are identified as US 7,027,465 B2, US RE44,904 E, US 6,832,249 B2, and US 7,760,664 B2 — not 7,289,456 and not RE43,704. Sources: https://npe.law.stanford.edu/patent/re44904 ; https://www.patsnap.com/resources/blog/litigation/commworks-v-extreme-networks-network-patent-dispute-patsnap/ ; https://www.patsnap.com/de/resources/blog/litigation/commworks-solutions-v-marvell-technology-networking-chip-patent-patsnap/

What I did NOT find (explicit uncertainty):

• No CAFC 2026 appeal, argument, or decision naming U.S. 7,289,456. My CAFC-facing searches returned 2026 decisions on unrelated patents (e.g., AudienceScience v. Google, Teva v. Lilly, Moskowitz v. Globus) and no docket for this patent.
• No IPR/PGR/CBM or reexamination record for 7,289,456 surfaced in my searches. The only reexam notice I encountered (Control No. 90/014,701) concerned an unrelated patent (US 8,130,775).
• Identify-by-number caution: US RE43,704 (the reissue linked to 7,289,456) and US RE44,904 (the patent asserted by CommWorks) are different reissue numbers and must not be conflated. Likewise, US 7,027,465 ("Determining and provisioning paths in a network," Gupta et al., Telcordia) is a related but distinct patent/application in the same family, not the same document as 7,289,456.

Adjacent assignment/licensing activity worth noting: the 2020‑2022 filings to Unwired Solutions, Inc. and Unwired Broadband, Inc. relative to CommWorks Solutions are recorded as licenses (with corrective assignments as to the nature of conveyance), not as outright assignments of title.

Reliability notes

• Title, inventors, filing/issue dates, abstract, claim text, and assignment/legal-status chronology above are taken from the authoritative patent document you supplied (Google Patents, fetched 2026‑09‑27) and are high confidence.
• Claim 22–28 scope: low confidence (source text truncated).
• Assignee-of-record: medium confidence — Google Patents itself disclaims accuracy of listed assignees, and a third-party wiki (wiki.golden.com) asserts assignment to "iconectiv," which I could not corroborate and which conflicts with the recorded Telcordia→Nytell→CommWorks chain. I would not rely on the iconectiv attribution.
• Litigation/CAFC status: medium confidence as a negative finding — no CAFC 2026 docket for 7,289,456 appeared in my searches, but absence in the search results I obtained is not proof of absence in PACER/CM‑ECF.

I'll search for litigation involving US patent 7289456.

Let me search more specifically for litigation involving the patent's owners and this patent number.

Let me search for litigation by the patent's owners (Nytell Software, CommWorks Solutions) and check the Unified Patents litigation portal.

Litigation Search Results for U.S. Patent No. 7,289,456

Bottom line: I could not identify any confirmed litigation specifically asserting U.S. Patent No. 7,289,456. Based on the searches I was able to run (Google Patents, PACER/court-docket aggregators, Unified Patents-style litigation portals, and general web searches), no case was found in which 7,289,456 was named as a patent-in-suit. I want to be explicit about this rather than guess, since a false case number or defendant would be worse than a "not found."

What I did find, and why it is not an answer

1. Patent family carries a litigation flag (unverified against the '456 patent itself).
The Google Patents record for US 7,289,456 displays a "Family has litigation" indicator, with a link to a Darts-IP first-worldwide-family litigation entry (family ID 28674372). This is a family-level flag — it tells us that some member of this patent family has been litigated, but it does not establish that 7,289,456 itself was asserted. The family here is the Telcordia routing/provisioning family (note the reissue USRE43704E1, which shares priority and is a separate document). I could not retrieve the underlying Darts-IP case list to confirm whether '456 specifically is in suit.

2. CommWorks Solutions, LLC is an active litigant — but on different patents.
Ownership chain per the patent record: Telcordia Technologies → Telcordia Licensing → TTI Inventions A LLC → Nytell Software LLC (2015) → CommWorks Solutions, LLC (2020). CommWorks has filed many recent infringement suits (2025–2026) in W.D. Tex., E.D. Tex., D. Del., D. Minn., etc., against Microchip, Marvell, Qualcomm, Texas Instruments, NXP, STMicroelectronics, u-blox, AVM, Digi, and others. However, in every case I pulled, the asserted patents were the Wi-Fi/802.11 family — 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 — not 7,289,456. So the CommWorks campaign is relevant context (a plausible future or parallel plaintiff) but is not itself evidence of litigation on '456.

3. One search hit used the shorthand "the '946 patent," but it is a different patent.
A PTAB petition referenced a "'946 patent" challenged in IPR2024-01250 (Samsung) involving multi-user detectors and legacy communication protocols. That is not US 7,289,456 — it is a different patent that happens to also end in "946." I flag it only so you know I saw it and correctly excluded it.

Caveats on this conclusion

• Coverage limits: My search was capped before I could complete targeted queries against the Unified Patents litigation portal (portal.unifiedpatents.com/litigation/), Darts-IP, and PACER directly for the exact number. Those sources are the most likely to hold a complete assertion history.
• Family reissue: Because USRE43704E1 is a reissue in the same family, any suit asserting the reissue could, after reissue, effectively implicate the '456 disclosure. If a party asserted the reissue rather than '456, my number-specific search would not have caught it.
• Termination of patent: The '456 patent's status is recorded as ceased/expired (adjusted expiration 2024-09-20), so the window for new assertions has closed, but earlier assertions (2007–2024) could still exist.

Recommended next steps to get a definitive answer

1. RPX Insight / Unified Patents — search by exact patent number ("7,289,456") rather than by owner.
2. Darts-IP family 28674372 — the source Google Patents itself cites for first family litigation.
3. PACER / CourtListener full-text search for the literal strings "7,289,456" and "7289456," restricted to "Patent" nature-of-suit.
4. Nytell Software LLC and CommWorks Solutions LLC docket sweeps in D. Del., E.D. Tex., and W.D. Tex., checking every complaint's patent list for the '456 number.

I have deliberately not supplied a plaintiff/defendant case caption, case number, jurisdiction, or filing date, because I could not verify any case asserting this specific patent. If you can authorize a further round of searches (or provide the Darts-IP/RPX output), I can complete the case-by-case table in the format you requested.

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.