US 8976673

I'll search for the specific patent number and check for any 2026 CAFC activity.

Let me check specifically for any litigation or IPR involving this Ericsson patent.

US Patent 8,976,673 — Verification and Summary

Sourcing note: The patent number was taken literally as 8,976,673 (= US 8,976,673 B2). Details below are from the Google Patents record (patents.google.com/patent/US8976673), Justia Patents, and the EPO DOCDB family listing for EP 2742655. I did not have direct live access to USPTO PatentCenter/Assignment or the CAFC docket in this session, so bibliographic data should be treated as high-confidence but not registry-verified.

1. Bibliographic Data

Family: US 13/208,251 → US 8,559,314 B2 (parent); US 14/025,477 → US 8,976,673 B2 (this continuation); WO 2013/021304 A1; EP 2742655 B1; JP 5973570 B2; KR 101956408 B1; CN 103718519 B; AU 2012293358 A1; BR 112014001401 A2; CA 2844860 A1; IN 2014DN00162A.

Note on the two US records: The Google Patents abstract and the Justia claim text for US 8,976,673 differ slightly from the published application US 2013/0039214 A1 (the parent's publication). In the granted '673 patent, claim 1 was narrowed to recite "at least one border switch … forming a border switch pair," whereas the parent publication recited "each border switch pair," and the shortest-path-tree/forwarding-table step was moved out of claim 1 into claim 8. So the '673 claims are narrower than the parent's — worth keeping in mind if comparing the two.

2. Abstract (verbatim, as listed for US 8,976,673)

"A method is implemented in a network element that functions as one of a plurality of controllers for one of a plurality of areas of a split architecture network. The controller provides a control plane for the area of the split architecture network where the controller is remote from a plurality of switches providing a data plane for the area of split architecture network. The controller facilitates optimized routing across the plurality of areas of the split architecture network by providing limited intra-area link cost data to other controllers of other areas of the split architecture network and to traditional routers of a network including the split architecture network. The limited intra-area link cost data provides costs of each possible shortest path traversal of the area of the controller without providing all internal link cost data."

3. Plain-Language Overview of the Independent Claims

Claim 1 — Method (independent)

A method performed in a controller that is one of several controllers, each governing one "area" of a split-architecture (SDN-style) network, where the controller is physically remote from the switches that actually forward packets. The controller's job is to share just enough internal cost information with other areas/traditional routers so end-to-end routing stays optimal, without dumping every internal link cost onto the network. Steps:

1. Learn the topology of its own area, including identifying at least one border switch — a switch with an external port that links this area to another area, or to a conventional ("traditional") router.
2. Compute the shortest path between that border switch and another border switch in the same area (the two together form a "border switch pair").
3. Store the cost of that shortest path in the controller's routing table.
4. Discover neighbors (another area's controller, or a neighboring traditional router) using a hello protocol — the neighbor being reachable via an external port of this area.
5. Exchange the link-state database with that neighbor, where the LSDB includes the border-switch-pair shortest-path cost.

Core idea: the intra-area path between any two border switches is abstracted as a single "virtual link" with an aggregated cost. That aggregated cost is embedded in ordinary OSPF messages and flooded to all areas, so every controller has a complete (inter-area + aggregated intra-area) topology picture and can run Dijkstra to compute true optimal paths — something the "external-cost-only" approach (FIG. 6) and the "multiple conflicting internal-cost messages" approach (FIG. 7) both fail to achieve.

Claim 10 — Network Element / Apparatus (independent)

The apparatus counterpart of claim 1. A network element acting as one of the area controllers (control plane remote from the data-plane switches) comprising:

• an ingress module (receive data) and an egress module (transmit data);
• a network processor executing: a controller module (provides control-plane functionality for the area), a topology learning module (determines the area topology, including border switch(es) with external ports), a shortest path calculation module (identifies the shortest path between a border switch pair for sharing with neighbors), a neighbor discovery module (finds neighbor controllers/traditional routers via a hello protocol), and a link state management module (exchanges the LSDB, which includes the border-pair shortest-route cost); and
• a routing table storage device storing routing tables, including shortest-path information within the area and between its border switches.

Dependent claims of note: claim 2 (send/receive hello packets on external ports); claims 3–4 (LSAs carrying external-link costs and border-pair shortest-path costs); claims 5–6 (advertising updated link status); claim 7 (initialize OSPF data structures); claim 8 (compute shortest-path tree rooted at the controller and update switch forwarding tables); claim 9 (update forwarding tables via OpenFlow). Claims 11–18 mirror these for the apparatus, with claim 16 reciting OpenFlow and claim 18 reciting the shortest-path-tree/forwarding-table update.

4. USPTO / CAFC 2026 Check

• CAFC 2026 dockets: I found no Federal Circuit appeal, IPR/PGR appeal, or district-court litigation in 2026 (or otherwise) involving US 8,976,673. Searches surfaced only unrelated Ericsson enforcement activity (the Lenovo/Motorola 4G/5G SEP campaign, ITC investigations, FRAND appeals), none of which concerns this patent.
• Caution — near-miss identifier: one search hit (a PTAB petition by Cirrex) repeatedly refers to a "the '673 patent" with a 1997/1999 priority and optical-filter subject matter. That is a different patent, not US 8,976,673. I am flagging it so it is not conflated with this patent.
• Uncertainty: I could not run a fully exhaustive docket-level query against PACER/CAFC or USPTO PatentCenter in this session. If precise litigation/assignment history is required, that should be confirmed directly against those registries. The absence of results should be read as "no evidence found," not as a certified negative.

5. Confidence Summary

Sources: https://patents.google.com/patent/US8976673/en · https://patents.justia.com/patent/8976673 · http://data.epo.org/pise-server/rest/collections/lgpi/EP2742655A1.pdf

I'll search for litigation involving US patent 8976673 across patent litigation sources.

Let me search more targeted litigation databases.

Let me search additional litigation-specific sources.

Findings: Litigation involving U.S. Patent No. 8,976,673

Bottom line: I found no litigation (district court, ITC, PTAB, or appellate) involving U.S. Patent No. 8,976,673.

What I searched

• Google Patents / FreePatentsOnline / Justia Patents entry for US8976673B2 — none of these list any litigation ("Litigation" / "Suits" tab) for this patent.
• General web searches for the exact numbers "8976673" and "8,976,673", and combinations with "litigation," "infringement," "complaint," "Ericsson," "case number."
• Patent-litigation–oriented material (Unified Patents–related PTAB filings, CourtListener/Recap dockets, DocketAlarm, CAFC opinions) surfaced through search.

No hit tied the number 8,976,673 to any plaintiff, defendant, court, or case number.

Important caution — avoid false positives

My searches returned several documents referring to a "'667 patent" that are not US 8,976,673. Do not conflate them:

Likewise, the Ericsson cases that appeared in results (Ericsson v. TCL, Ericsson v. Apple, Ericsson v. Micromax/Intex/Xiaomi/Gionee, Ericsson v. Asustek at the UPC, and the ITC/FRAND matters) assert standard-essential 2G/3G/4G cellular patents — not US 8,976,673, which is a split-architecture/OpenFlow OSPF routing patent and is not a standards-essential patent.

Context on the patent itself (from the patent record)

• Patent: US 8,976,673 B2, "Implementing OSPF in split-architecture networks"
• Assignee: Telefonaktiebolaget LM Ericsson (publ)
• Inventors: Kiran Yedavalli, Neda Beheshti-Zavareh, Ying Zhang
• Application: 14/025,477, filed 2013-09-12; continuation of 13/208,251 (which issued as US 8,559,314 B2)
• Priority: 2011-08-11; granted: 2015-03-10; anticipated expiration: 2031-08-11
• Family members (per Google Patents): US8559314B2, EP2742655B1, JP5973570B2, KR101956408B1, CN103718519B, AU2012293358A1, BR112014001401A2, CA2844860A1, IN2014DN00162A, WO2013021304A1

The patent page shows only "Cited By (3)" (later patents citing it, e.g., US20130028070A1, US10142220B2, US11349557B2) and "Families Citing this family (51)" — i.e., forward citations, not litigation.

Limitations and recommended verification

• I could not complete the full set of planned searches (my tool use was cut off), and I did not have direct access to Docket Navigator, PACER, or the Unified Patents litigation portal's paywalled/structured case lists. My conclusion rests on the absence of any indexed litigation reference to this exact number in public search results.
• Because patent numbers are easy to transcribe incorrectly, if you have a lead suggesting this patent was asserted, verify with a literal number search in Docket Navigator or PACER (search "8,976,673" exactly) and cross-check against the sibling patent US 8,559,314. It is possible that a case asserted the parent continuation (the '314 patent) rather than the '673 patent.

If you have a specific case name or docket number you believe involves the '673 patent, I can attempt to verify it directly.

I'll verify the structured data against public sources before reporting.

Let me run a few more targeted checks on the patent's litigation history and any PTAB challenge.

One more verification pass on PTAB/litigation dockets for this patent.

Proceedings overview

Total AIA trial proceedings on US 8,976,673: 0. The structured USPTO Open Data Portal block supplied with this task returns an empty proceedings list, and my independent web searches (PTAB docket aggregators, E2E-style petition PDFs, Federal Circuit/CourtListener materials, and news coverage) surfaced no IPR, PGR, or CBM petition naming this patent — not even a denied or dismissed one. Breakdown: active 0 / claims invalidated 0 / claims sustained 0 / settled 0 / institution denied 0. The bottom line for a defendant is that there is no PTAB-based invalidity shortcut and no claim has been canceled — all 18 claims of the '673 patent remain presumptively valid and enforceable, so any validity attack must be built from scratch (district court, or a fresh petition you would have to file).

A necessary caveat on confidence: the absence finding rests on the structured ODP data (canonical) plus keyword searches that returned nothing on-point. I did not retrieve a screenshotted PTAB E2E party/patent search page, so I cannot rule out a recently filed petition that no index has picked up. Treat "zero proceedings" as high-confidence-but-verifiable, and re-pull PTAB E2E by patent number before relying on it in a filing or an opinion letter.

Proceedings

None to list. There is no proceeding number, petitioner, panel, institution decision, Final Written Decision, settlement, or appeal to report for US 8,976,673. Any entry in this section would be invented, and I will not do that.

Context that matters for the "no PTAB activity" finding

• Patent identity (verified against the authoritative text): US 8,976,673 B2, "Implementing OSPF in split-architecture networks," inventors Kiran Yedavalli, Neda Beheshti-Zavareh, Ying Zhang; assignee Telefonaktiebolaget LM Ericsson AB; application 14/025,477 filed 2013-09-12; continuation of US 13/208,251, which issued as US 8,559,314 B2; priority 2011-08-11; granted 2015-03-10; anticipated expiration 2031-08-11; 18 claims.
  Source: https://patents.google.com/patent/US8976673/en
• The sibling patent is also clean. My searches found no AIA trial naming US 8,559,314 either. So the absence of PTAB activity is a family-level pattern, not an artifact of which continuation someone happened to check.
• Cited-by / family activity is not PTAB activity. The Google Patents page lists three third-party citations (e.g., US 10,142,220 to Hewlett Packard Enterprise; US 2013/0028070 A1, an Ericsson split-architecture application) and a 51-entry "families citing this family" list. Those are forward citations in prosecution, not challenges to this patent. Do not confuse them with IPR/PGR numbers.
• No Federal Circuit appeal exists for this patent because there was no PTAB FWD to appeal. I found no CAFC docket or CourtListener entry tied to US 8,976,673 validity.

Strategic summary

Claim status. All claims are UNTESTED by the PTAB. Nothing is CANCELED; nothing is SUSTAINED in the sense of surviving an AIA trial. Claims 1–18 stand exactly as issued, with claim 1 (method, controller-centric) and claim 10 (network element / apparatus) as the independent claims and claims 2–9 and 11–18 as dependents. Contrast this with the routine situation for a heavily asserted patent, where you can point to an FWD canceling the independent claims and tell the demand-letter writer that their theory is built on dead claims. That argument is not available here.

Estoppel landscape. Because no petition was ever filed and no trial instituted, § 315(e)(2) estoppel is a blank slate — there is no petitioner, no privy, and no "grounds raised or reasonably could have been raised" to trace. This cuts both ways. The upside for a defendant: you are not blocked from any prior-art ground, and there is no earlier petitioner's expert record or claim-construction position to inherit or distinguish. The downside: there is also no free invalidity roadmap. In district court you would still have to satisfy the clear-and-convincing standard, and note that OSPF (RFC 2328) and OpenFlow prior art are both decades old, which cuts toward a § 103 theory built on standard-document references — but the patent's stated novelty is precisely the abstraction of intra-area path costs between border-switch pairs into a single aggregated cost propagated as an LSA (see the "OSPF with Abstracted Intra-Area Path Costs" section). That is a fairly specific architectural limitation, and a § 103 attack would need art that discloses cost aggregation, not merely OSPF generally.

Pattern signals. No serial petitioner, no defensive aggregator (nothing tying Unified Patents or a comparable entity to this patent), and no Ericsson appeal activity on this family. The real pattern is the opposite of a "troll" patent: this is a practicing-entity portfolio patent held by Ericsson's IPR & Licensing group, i.e., a standards-oriented networking patent that appears to have gone largely unasserted in standalone litigation. That matters for posture: patents that are never asserted rarely attract IPRs, so the absence of PTAB activity here is more plausibly explained by non-assertion than by the patent being so weak that no one bothered. Do not read the zero-count as a strength signal either way.

Recommended next steps

• If you are a defendant and the demand letter cites claims 1–18: you cannot point to a cancellation. Run PTAB E2E (https://ptab.uspto.gov) and the ODP API by patent number on the day you respond to confirm the zero-count, then build your invalidity case from primary references. Start with RFC 2328 (the patent itself cites OSPF) plus RFC 3630/5310-style "OSPF area abstraction / virtual-link cost" art, and the OSPF "aggregate cost" literature, which is the closest analog to the claimed abstraction.
• If you are considering filing a petition: there is no § 315(b) one-year bar running against you yet (no prior petitioner), so no estoppel exposure from an earlier filer. But a petition must be drafted now and cleared for § 102/§ 103 grounds and § 325(d) (the examiner will have considered OSPF-family art already). Also budget for the current institution environment — discretionary denial practice is aggressive, so include a Sotera stipulation if you are in parallel litigation and consider a Fintiv analysis up front.
• If no proceeding has appeared by the time you need to act, say so plainly in any opinion letter: absence of PTAB activity on a 2011-priority Ericsson networking patent is a signal that it has not been a litigation target, not that it has been tested and survived. Frame validity risk and prior-art search needs accordingly.

Sources used: Google Patents patent page (authoritative full text, claims, family, citations): https://patents.google.com/patent/US8976673/en; sibling continuation US 8,559,314: https://patents.google.com/patent/[US8559314B2](/patent/US8559314B2)/en. No PTAB or Federal Circuit opinion is cited because none exists for this patent.

I'll research the assignment record for US 8976673. Let me check the primary sources.

Let me look for the specific assignment record and Ericsson's ownership status.

Let me check for any litigation involving this patent and any assignment records.

Assignment & Ownership Analysis — US 8,976,673 B2

"Implementing OSPF in split-architecture networks" — Appl. No. 14/025,477 (continuation of 13/208,251 / US 8,559,314 B2)

Data caveat up front: The USPTO Assignment Center record could not be retrieved with a reel/frame number from the sources reachable in this session. What is verifiable is the Google Patents legal-events entry (2025-01-23 reassignment) and the assignee-of-record fields. The reel/frame and the recording correspondent are therefore reported as not retrieved rather than guessed. See the verification links at the end.

Inventors

• All three are listed jointly on both the parent (US 8,559,314, filed 2011-08-11) and this continuation. The work is Ericsson's "split-architecture / OpenFlow" research effort of ~2011–2013, so all three are attributable to Ericsson at filing.
• Mobility note (not a "mass departure" finding): Kiran Yedavalli later appears as an inventor on a separate cluster of 2019–2023 Cisco Systems patents (per Patent Leaderboard), i.e. he eventually left Ericsson. The timing of that departure cannot be fixed to within 12 months of the 2011 filing on the evidence available, so it is not evidence of a pre-fire-sale inventor exodus. Neda Beheshti-Zavareh and Ying Zhang show no comparable post-filing reassignment signal in the retrieved data. No unusual all-inventors-departed pattern is established.

Original assignee

Telefonaktiebolaget LM Ericsson (publ) — Stockholm, Sweden ("Ericsson"), named on the face of the issued patent.

• Primary line of business: operating telecommunications network-equipment vendor (RAN, transport, core, and network-management gear). This is a large, publicly traded operating company — not a holding vehicle.
• Product embodiment: Ericsson's split-architecture / SDN control work (the subject matter of the claims — an OSPF process run on a remote controller for a split-architecture area) is part of Ericsson's commercial transport and cloud/SDN product lines. It is a genuine operating-company R&D asset, not a paper patent.
• Current status: operating. Ericsson remains an active global vendor. No bankruptcy, dissolution, or change-of-name event affecting this patent was found.
• Current assignee of record: Google Patents still lists Telefonaktiebolaget LM Ericsson AB as Current Assignee. The patent did not leave Ericsson.

Assignment timeline

Only one recorded post-filing assignment appears for this patent — the standard inventor-to-company assignment. There is no chain of LLC transfers, no securitization, and no transfer-to-asserter.

• Executed: on/around filing (2011-08-11) / recorded 2015-01-23 — Reel/Frame: not retrieved from source
  • Conveyance: Assignment (inventor → company)
  • Assignor: Beheshti-Zavareh, Neda; Yedavalli, Kiran; Zhang, Ying (individually)
  • Assignee: Telefonaktiebolaget L M Ericsson (publ)
  • Correspondent: not captured in the retrieved record (reported as unknown rather than fabricated). No recurrence flag can be raised on one entry.
  • Context: routine employment/new-hire invention assignment perfecting Ericsson's title; recorded in connection with the continuation application (14/025,477, filed 2013-09-12) in the months before the 2015-03-10 grant.

Important cross-reference — the Ericsson "privateering" deal that does NOT touch this patent. In January–February 2013 Ericsson sold 2,185+ issued US/international patents and applications to Unwired Planet, Inc. (an NPE), for a revenue-share plus a license back — a textbook privateering arrangement (Unwired Planet → later PanOptis/Optis). That portfolio was 2G/3G/LTE cellular SEPs. This patent is not in that transfer: Ericsson remains the assignee of record, the deal closed February 2013, and this continuation was not even filed until September 2013. So the most famous Ericsson-NPE signal in the ecosystem is a near-miss for this asset, not part of its chain.

If the Assignment Center shows additional entries when queried live, the analysis should be re-run — but no second assignment is surfaced by Google Patents legal events, which would normally display post-issuance transfers.

Timeline diagram

timeline
    title Ownership of US 8976673
    2011 : Priority and parent filed by Ericsson
    2013 : Ericsson sells other IP to NPE
    2013 : Continuation application filed
    2015 : Inventor assignment recorded to Ericsson
    2015 : Patent issued to Ericsson

NPE / troll-pattern signals

1. Shell-entity transfer — not present. No LLC assignee anywhere in the chain. Assignee of record is Telefonaktiebolaget LM Ericsson (publ), a Swedish operating company. No "IP/Holdings/Ventures" suffix, no registered-agent service address.

2. Known asserter in the chain — not present (for this patent). The current assignee (Ericsson) is not on any NPE list. The chain contains zero Acacia / Marathon / IV / Wi-LAN / Conversant / Pendrell / Unwired Planet / PanOptis entities. Note the ecosystem proximity: Ericsson did run a privateering program with Unwired Planet in 2013, but per the assignee-of-record data this patent was not among the transferred assets, so no asserter ever held it.

3. Repeat correspondent across the chain — unclear / not assessable. Only one assignment event is recorded, so recurrence cannot be tested. The correspondent name and firm were not retrievable in this session and are not guessed. Single appearance would not be a finding in any event.

4. Cascading transfers — not present. One transfer (inventors → Ericsson). No chained LLCs, no shared correspondent addresses, no serial re-recordings within 24 months.

5. Pre-litigation transfer — not present. No assignment within 6 months before any suit; in fact no infringement suit naming US 8,976,673 was located. The sole 2015-01-23 recording is an inventor-assignment, not a litigation-enabling transfer to an asserter, and there is no suit on the other side of it.

6. Bankruptcy fire-sale — not present. Ericsson has not filed Chapter 7/11; this patent was not sold in any insolvency proceeding.

7. Privateering — not present for this patent. Ericsson's January–February 2013 Unwired Planet transaction is a documented privateering arrangement (sale to an NPE with revenue share and license-back), but the assignee-of-record evidence places this continuation outside that portfolio. Flagging it only as contextual near-miss, not as a finding.

8. Defensive aggregator (anti-NPE) — not present. Chain does not terminate at RPX, AST, LOT, Unified Patents, or OIN.

Signal count: 0 present, 7 not present, 1 unclear (correspondent recurrence — untestable on a single record).

Verdict

Insufficient data — the dossier contains only the original inventor-to-company assignment (recorded 2015-01-23, conveying title from Beheshti-Zavareh / Yedavalli / Zhang to Telefonaktiebolaget L M Ericsson (publ)), with no post-issuance transfer of any kind surfaced. That single-record posture is itself the finding: the original assignee, a large operating telecom-equipment vendor, still owns the patent, and there is no LLC, no asserter, no litigation, and no defensive-aggregator endpoint in the chain. Zero NPE signals are present, so this is not an NPE matter; it is a clean operating-company ownership record rather than a monetization chain.

Verification links

• USPTO Assignment Center (search by patent number 8976673 / appl. 14/025,477; the live record will supply the reel/frame and correspondent that could not be retrieved here): https://assignmentcenter.uspto.gov/ ; alternate index: https://assignment.uspto.gov/patent/index.html
• Google Patents legal events (shows the 2015-01-23 reassignment to Telefonaktiebolaget L M Ericsson (PUBL); assignors Beheshti-Zavareh, Yedavalli, Zhang; current assignee Ericsson): https://patents.google.com/patent/US8976673/en
• Parent patent US 8,559,314 B2 (same family, same inventors): https://patents.google.com/patent/[US8559314B2](/patent/US8559314B2)/en
• Ericsson → Unwired Planet privateering deal (contextual near-miss, Jan/Feb 2013): https://www.iam-media.com/article/unwired-planet-sell-patent-business-30-million-buyer-increases-its-stockpile-of-ericsson-assets

Confidence note: inventor, assignee, dates, and family relationships are high-confidence (patent text + Google Patents). The one gap is the reel/frame and recording correspondent for the 2015-01-23 assignment, which I could not retrieve and have deliberately left blank rather than estimated.

I'll research the specific prior-art citations for US 8,976,673. Let me pull the reference list and verify each reference.

Let me pull details on the two US patent references cited — Ansari (2006/0092940) and Medved (2012/0144066) — plus verify dates.

Let me retrieve the two cited US patent publications directly.

Prior-Art Citations for US 8,976,673 — Reference-by-Reference § 102 Analysis

Patent under review: US 8,976,673 B2, "Implementing OSPF in split-architecture networks" (Appl. 14/025,477; filed 2013-09-12; granted 2015-03-10; priority 2011-08-11; assignee Telefonaktiebolaget LM Ericsson (publ); inventors Yedavalli, Beheshti-Zavareh, Zhang; Primary Examiner Pao Sinkantarakorn).

Scope note. "Patent citation for 8976673" is read literally as the "Referenced Cited" (backward citation) list on the face of the patent. For this patent that list contains exactly two U.S. patent documents, plus four items of non-patent literature (NPL). That is the complete citation set — I have not padded it with similarly numbered patents. The "Cited By" entries (US 2013/0028070 A1, US 10,142,220 B2, US 11,349,557 B2) are forward citations that post-date the patent and are not prior art; they are noted at the end only for completeness.

Sourcing caveat (stated up front). I retrieved the citation list from Justia Patents and Google Patents for US 8,976,673, and verified the Ansari reference. My search step limit was reached before I could pull the full text or filing date of the Medved reference, so I have not attributed any disclosure to it and have flagged its § 102 posture as unverified. I could not run a live USPTO PatentCenter/Patent Full-Text query by the exact number this session; the list below is as reported by those two sources.

The complete backward-citation list (as listed for US 8,976,673)

A1 — US 2006/0092940 A1 (Ansari et al.) — "Softrouter protocol disaggregation"

• Full citation: U.S. Patent Application Publication US 2006/0092940 A1, "Softrouter protocol disaggregation," inventors Furquan Ansari, Martin Havemann, Tirunell Lakshman, Thyagarajan Nandagopal, Ramachandran Ramjee, Thomas Woo (Bell Labs / Lucent–Alcatel group). App. No. 11/147,472; filed June 8, 2005; published May 4, 2006; later granted as US 8,068,408 B2. Related EP publication EP 1 653 688 A1 (2006-05-03).
  Sources: https://patents.justia.com/patent/20060092940 ; the publication is repeatedly cited ecosystem-wide as "Softrouter protocol disaggregation, Ansari et al., 2006-05-04."
• Dates: published 2006-05-04, i.e. more than one year before the 2011-08-11 priority date → qualifies as pre-AIA § 102(b) prior art (printed publication/patent-bar art). Also § 102(a)/(e) depending on the particular claim's effective date.
• Brief description: The Softrouter is the canonical pre-OpenFlow "disaggregated router" architecture. It separates the control plane from the forwarding plane: control elements (CEs) run the routing protocols (OSPF, BGP/IDRP) and are physically separate from the forwarding elements (FEs) that actually move packets, with dynamic binding between a CE and the FEs it controls. The document expressly discusses OSPF convergence and OSPF's reliable flooding mechanism in that disaggregated setting. It therefore discloses the control-plane/data-plane separation and remote-controller-manages-forwarding-elements concept that animates the preamble of claims 1 and 10.
• § 102 potential — realistic assessment: NO anticipation of any claim. Anticipation requires a single reference to disclose every element of the claim arranged as in the claim (Net MoneyIN v. VeriSign; In re Robertson; MPEP 2131). Ansari is a strong teaching of the architecture (split control/forwarding, remote control elements running OSPF), i.e. the preamble elements of claims 1 and 10:
  • claim 1 preamble — "controller … remote from a plurality of switches providing a data plane"; claim 10 preamble — same architecture plus ingress/egress/network-processor.
    But it does not disclose the point of novelty: computing the shortest path between a border-switch pair in an area and flooding that aggregated border-pair cost as link-state data (the "limited intra-area link cost data" limitation, claims 1, 4, 10, 13), nor the hello-protocol neighbor-controller/traditional-router discovery, nor the shortest-path-tree/forwarding-table-update limitations of claims 8–9/16/18. Because at least these elements are missing, no claim is anticipated under § 102 by Ansari standing alone.
• Where it actually bites (this belongs to the § 103 analysis): Ansari is the closest single architecture reference and the most natural primary reference for the "split architecture / remote controller" preamble of claims 1 and 10. It is § 103 material, not § 102 material.

A2 — US 2012/0144066 A1 (Medved et al.)

• Full citation: U.S. Patent Application Publication US 2012/0144066 A1, inventors Medved et al.; published June 7, 2012; filing date and title not retrieved in this session (search step limit reached).
• Dates / § 102 eligibility — material problem: The publication date 2012-06-07 post-dates the 2011-08-11 priority date of the '673 patent. On its face, therefore, A2 is not § 102(a) or § 102(b) art against the claims. It could qualify only as pre-AIA § 102(e) art (an earlier-filed, later-published U.S. application/patent), which requires its effective U.S. filing date to precede 2011-08-11. That date was not verifiable here. The fact that the examiner cited it is consistent with a § 102(e) reference or with citation as background; I cannot confirm which.
• Brief description: Not retrieved. I will not attribute any disclosure to this reference. Its content must be pulled from the primary document before it is relied upon.
• § 102 potential — cannot be assessed on the present record. If (and only if) its effective filing date precedes the '673 priority date, it would be § 102(e) art as to any claim whose subject matter it expressly discloses; absent the full text, no claim can be tied to it. Verify first.

A3 — McKeown et al., "OpenFlow: Enabling Innovation in Campus Networks"

• Full citation: N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, J. Turner, "OpenFlow: Enabling Innovation in Campus Networks," ACM SIGCOMM Computer Communication Review, March 14, 2008 (6 pages). Cited on the face of the '673 patent.
• Dates: 2008-03-14, more than one year before 2011-08-11 → § 102(b) art.
• Brief description: Introduces the OpenFlow split-architecture model in which the control plane is separated from the data plane and run on a (remote) controller, and the controller programs the switches' flow/forwarding tables over a secure channel. This is the seminal reference for the "controller remote from switches providing a data plane" concept.
• § 102 potential — NO anticipation of any independent claim; at most background for dependent claims. McKeown teaches the controller/switch split and flow-table programming (pertaining to the preamble of claims 1/10 and to the "updating forwarding tables … using the OpenFlow Protocol" limitations of claims 9 and 16). It discloses no OSPF area topology learning, no border-switch-pair shortest-path computation, and no link-state-database exchange of an aggregated border-pair cost. Because those elements are absent, it cannot anticipate claims 1–18 as arranged; it is § 103 art, principally for claims 9/16 and the preambles.

A4 — OpenFlow Switch Specification v1.1

• Full citation: "OpenFlow Switch Specification, Version 1.1," Open Networking Foundation / openflow.org, February 28, 2011 (56 pages). Cited on the face of the '673 patent.
• Dates: 2011-02-28, i.e. within one year before the 2011-08-11 priority date → § 102(a) art (printed publication before the invention date; not § 102(b) because it is less than a year before priority).
• Brief description: The standardized controller-to-switch protocol specification: flow-table structure, controller↔switch channel, multiple controllers, table population. Relevant to the apparatus elements (network processor / controller module / programmable forwarding tables) and to the OpenFlow forwarding-table-update limitations (claims 9, 16).
• § 102 potential — NO anticipation. It discloses the OpenFlow control-plane mechanism only. It says nothing about OSPF areas, border switches, border-pair shortest paths, or LSDB flooding of aggregated intra-area cost. No claim is anticipated; it is § 103 art for the OpenFlow/controller programming elements.

A5 — J. Moy, "OSPF Version 2," RFC 2328

• Full citation: J. Moy, "OSPF Version 2," IETF Network Working Group, RFC 2328, April 1998 (204 pages). Cited on the face of the '673 patent; the '673 specification itself relies on it.
• Dates: 1998-04 → squarely § 102(b) art.
• Brief description: The core OSPF specification. It discloses, among other things: areas and Area Border Routers (ABRs); the Hello protocol for neighbor discovery/adjacency on each interface; Link State Advertisements and reliable LSDB flooding; Dijkstra SPF with the router as root; Router-LSA interface-state description; and — importantly — virtual links (§ 15), where a multi-hop path across a transit area between two border routers is represented in the LSDB as a direct (unnumbered point-to-point) link carrying that path's cost, plus area-range/address-summary aggregation (§ 12.4.3), where the ABR advertises a single summarized cost for summarized internal reachability.
• § 102 potential — NO anticipation of the claims as a whole, despite broad disclosure. RFC 2328 discloses the routing mechanics recited across claims 2, 3, 5, 6, 7 (hello packets on ports; LSAs carrying interface/link cost; LSA updates on state change; initializing OSPF data structures) and the SPF/Dijkstra and LSA-flooding elements underlying claim 8/18. But it does not disclose the claim 1/10 setting of an SDN-style controller that is remote from the switches of an area — RFC 2328 presumes a conventional integrated router running OSPF for itself. Under the "arranged as in the claim" test, that missing element defeats anticipation of every independent claim, and the dependent claims fall with their bases. The closest single-reference disclosure is via virtual links / area-range aggregation, which teach border-to-border cost abstraction within OSPF but in a non-split-architecture, non-controller context.
• Where it actually bites: RFC 2328 is the primary § 103 reference for nearly all method/apparatus elements, and its virtual-link and area-range teachings are the closest art to the patent's stated novelty (aggregating a border-pair path into one costed link). It is § 103 material, not standalone § 102 material against the claims as written.

A6 — "Open Shortest Path First," Wikipedia (retrieved 2011)

• Full citation: "Open Shortest Path First," Wikipedia; ~14 pages; retrieved in 2011 per the patent's citation.
• Dates: Retrieved 2011 → § 102(a) art (and possibly § 102(b) depending on retrieval date relative to 2011-08-11). As a tertiary encyclopedic summary it adds little beyond RFC 2328.
• Brief description: General encyclopedic treatment of OSPF — areas, LSAs, SPF, hello — i.e. background.
• § 102 potential — NO anticipation. It is a summary of RFC 2328 and contains none of the split-architecture controller or border-pair cost-abstraction features. Background/§ 103-filler only.

Bottom-line § 102 conclusion

No claim of US 8,976,673 (claims 1–18) is anticipated under 35 U.S.C. § 102 by any single cited reference. Each cited reference fails the strict "every element arranged as in the claim" test:

• Ansari (A1) and the OpenFlow references (A3, A4) teach the split-architecture / remote-controller premise but none of the OSPF intra-area border-pair cost aggregation — so they cannot anticipate claims 1/10, and they leave the dependent claims' bases unsupported.
• RFC 2328 (A5) and Wikipedia (A6) teach OSPF's mechanics (hello, LSAs, LSDB, SPF, and even border-to-border cost abstraction via virtual links/area ranges) but not the controller-centric split architecture recited in the preambles of claims 1/10.
• Medved (A2) cannot be assessed and is, on its face, not § 102(a)/(b) art because it published after the priority date; only § 102(e) eligibility (unverified filing date) could make it relevant.

Accurate characterization: these are § 103 obviousness references, not § 102 anticipation references. The single most relevant patent citation is US 2006/0092940 A1 (Ansari), "Softrouter protocol disaggregation" — it is the closest architectural art (disaggregated control/forwarding with OSPF in the control elements) and would be the natural primary reference for the preamble of claims 1 and 10. The single most relevant disclosure on the merits is RFC 2328 (especially its virtual-link and area-range cost-abstraction teachings), which overlaps the patent's stated novelty but lacks the split-architecture controller. Neither alone anticipates; a combination would be required, which moves the analysis to § 103 — the ground already developed in the earlier "Obviousness" section (RFC 2328 + OpenFlow, optionally with Softrouter, for the controller-side architecture).

Non-prior-art "Cited By" references (listed only to avoid conflation)

These appear as forward citations on the '673 patent and are not prior art:

• US 2013/0028070 A1 — Beheshti-Zavareh et al. (Ericsson) — 2013-01-31.
• US 10,142,220 B2 — Hewlett Packard Enterprise Development LP — 2018-11-27.
• US 11,349,557 B2 — AT&T Intellectual Property I, L.P. — 2022-05-31.

Caveats and recommended verification

1. The patent citation set contains only two U.S. patent documents (Ansari, Medved). If you expected more, note that the '673 patent's face relies heavily on NPL (OpenFlow paper, OpenFlow 1.1 spec, RFC 2328, Wikipedia) rather than on many U.S. patents.
2. Medved (US 2012/0144066 A1) is the one genuine gap. I could not retrieve its title, filing date, or content within this session. Its § 102 posture depends entirely on whether its effective filing date precedes 2011-08-11 (making it pre-AIA § 102(e) art). Pull the primary document (Google Patents / USPTO PatentCenter) before relying on it.
3. No live USPTO registry query was completed. The citation list above is as reported by Justia Patents (https://patents.justia.com/patent/8976673) and Google Patents (https://patents.google.com/patent/US8976673/en). For a filing/opinion-letter-grade list, re-run the patent number in USPTO PatentCenter / the Patent Public Search "Referenced By / References Cited" views.
4. Do not conflate identifiers. A search for the digits "8976673" also returns unrelated hits (e.g., an IEEE DOI 10.1109/PEEIC47157.8976673 and a Korean application number KR 20060092940A for a substrate-transfer robot that merely share the same digit string as the Ansari U.S. publication number 2006/0092940). The prior art above is tied to the U.S. publication US 2006/0092940 A1 (Ansari), not to the Korean application.

Sources: Google Patents, https://patents.google.com/patent/US8976673/en (citation list, prior-art keywords/date, forward citations); Justia Patents, https://patents.justia.com/patent/8976673 (Referenced Cited: US 2006/0092940 A1 Ansari; US 2012/0144066 A1 Medved; McKeown OpenFlow 2008; OpenFlow v1.1 2011-02-28; RFC 2328; Wikipedia OSPF; Primary Examiner Pao Sinkantarakorn); Justia Patents, https://patents.justia.com/patent/20060092940 (Ansari "Softrouter protocol disaggregation," filed 2005-06-08, published 2006-05-04, granted US 8,068,408). No representation is made about the non-retrieved Medved reference.

I'll build the § 103 analysis on the prior-art set already established. Let me first try to verify the two reference titles the Prior Art section flagged as unverified, since their scope matters to the combination analysis.

The searches returned only noise (unrelated "Ansari"/"Medvedev" hits). Let me try direct identifier lookups.

P2 is now identified: US 2012/0144066 A1 (Medved et al.), "Dynamically generating application-layer traffic optimization protocol maps." Let me confirm its filing date/assignee (which controls § 102(e) availability) and make one more attempt at P1.

Obviousness Analysis Under 35 U.S.C. § 103 — U.S. Patent No. 8,976,673 B2

"Implementing OSPF in split-architecture networks" — Appl. No. 14/025,477; priority 2011-08-11; granted 2015-03-10

Built on the earlier dossier sections. This analysis uses (and does not repeat) the Prior Art, Claim-status, and Assignment sections already generated. Where it must correct or sharpen an earlier finding, it flags that explicitly.

1. Framework and one piece of new evidence

1.1 Governing law

Because the '673 patent is a straight continuation of Ser. No. 13/208,251 (filed 2011-08-11) and every claim is supported by that pre-AIA parent, the pre-AIA § 103 regime applies (Graham v. John Deere; KSR Int'l v. Teleflex; MPEP 2141–2143). The critical enquiry is:

1. scope and content of the prior art;
2. differences between the prior art and the claims;
3. the level of ordinary skill; and
4. whether a POSITA would have had a reason/motivation to combine the references with a reasonable expectation of success.

*(Housekeeping flag: the Prior Art section noted the body of the '673 patent renders the OSPF standard once as "RFC 23278." The correct reference — and the one actually cited on the face of the patent — is RFC 2328 (Moy, OSPF v2, Apr. 1998). I treat RFC 2328 as the reference throughout.)*

1.2 New evidence obtained this session — P2 is now VERIFIED (this upgrades the prior-art section)

The Prior Art section left P2 = US 2012/0144066 A1 (Medved et al.) as an unverified number/date with no title. I verified it this session:

Sources: https://patents.google.com/patent/US20120144066 · https://www.freepatentsonline.com/[9413847](/patent/9413847).html · EP counterpart EP2461547 (filed 2011-11-30): https://search.virtualpatentoffice.com/... / https://patent.public.lu/fo-eregister-view/search/details/511191369_EPV

This matters enormously to the § 103 case. P2 does not merely disclose "link-state mechanics." Its express disclosure is:

"…computing, with the ALTO server, an ALTO cost for a pair of … subsets of topological groupings (PIDs) of an ALTO network map based at least on the routing information … [and] generating an ALTO cost map that includes an entry that specifies the ALTO cost between the first member and second member of the pair of PIDs." (US 2012/0144066, Summary [0012])

P2 therefore teaches, in substance: (i) an entity remote from the forwarding devices that assembles network topology by listening to routing-protocol updates (an IGP/BGP "snoop"), (ii) aggregates that topology into groupings (PIDs) so that the internal detail is not exposed, and (iii) exposes only pairwise aggregated costs between the groupings for use in path selection. That is the conceptual heart of the '673 abstraction. P2 is now the single most dangerous reference in the set for the aggregation limitation — and it was already before the examiner.

(For completeness: P1 = US 2006/0092940 A1 (Ansari et al.) remains unverified — repeated searches returned only noise. I do not guess its scope and it does not carry the analysis below.)

1.3 Level of ordinary skill in the art (PHOSITA)

A POSITA here is an engineer with a B.S. in EE/CS (or equivalent) and ~2–5 years' experience in IP routing / IGP design, familiar with RFC 2328 (OSPF areas, Hello, LSAs, SPF), and — by 2011 — with OpenFlow/SDN controller-switch separation (the McKeown 2008 paper and the OpenFlow 1.1 spec are the canonical references; N1, N2). That person would know both the OSPF area-abstraction model and the newly commercialized centralized-controller model, and would routinely design across the two.

2. Claim construction of the limitations that decide the case

Three phrases carry the entire obviousness dispute. Construing them narrowly tends to save the patent; construing them according to their plain meaning (and the specification) tends to sink it.

Net: the patent's stated point of novelty is not the OSPF mechanics and not the controller-switch split — both are old. It is the representation choice: model the intra-area path between border switches as a direct link with an aggregated cost, and flood that (not the internal map). That is a data-representation/abstraction choice, which is the classic category of subject matter that § 103 reaches when the abstraction is known in the art.

3. Element-by-element mapping

3.1 Independent claim 1 (method)

Reading: N3 supplies (b)–(f) as OSPF mechanics; N1/N2 supply the architecture (remote controller/data-plane split); P2 supplies the express abstraction step ("aggregate into groupings … expose only pairwise costs") that the patent calls its point of novelty. No single reference supplies all elements — which is why the attack is a § 103 combination, not § 102 (consistent with the Prior Art section's conclusion).

3.2 Independent claim 10 (network element)

Same mapping at the apparatus level: N1/N2 disclose the network element with ingress/egress and a processor running a controller module programming switch flow tables; N3 discloses the shortest-path calculation and link-state management functions and a routing-table store; P2 discloses the topology-learning module (a "topology information base"/BGP-IGP listener that "assembles topology information") and the pairwise-cost generation for external sharing. The "routing table storage device" is any conventional memory — N3.

4. The § 103 combinations, ranked by strength

I apply the KSR/MPEP 2143 rationales in brackets for each.

Combination 1 (STRONGEST): N1 (McKeown 2008) or N2 (OpenFlow 1.1) + N3 (RFC 2328) + P2 (US 2012/0144066)

This is the combination a defendant would lead with.

• N1/N2 + N3 is the natural, indeed inevitable, pairing: a centralized OpenFlow controller tasked with computing paths for its switches must run some routing protocol, and OSPF is the dominant IGP of record. Motivation = [MPEP 2143 (D): applying a known technique (OSPF) to a known device (the SDN controller) ready for improvement] and [rationale (F): design incentive / market forces of the SDN transition]. The result (a controller that computes routes and programs flow tables) is predictable — [rationale (A)].
• Adding P2 supplies the missing abstraction. P2 solves the same problem the '673 patent frames — how to let an external consumer compute optimal paths without exposing the internal topology — and it does so by grouping nodes and exposing pairwise aggregated costs only. Motivation to graft P2's abstraction onto the N1/N2+N3 system = [rationale (C): known technique to improve similar devices in the same way], [rationale (F): the same design incentive], and [rationale (G): P2 itself provides the teaching/suggestion/motivation] — P2's stated advantage is exactly that "imported" topology can be "filtered to exclude private information" while still supporting path optimization.

The patent's own specification argues that the "external-cost-only" approach (FIG. 6) and the "multiple conflicting internal-cost messages" approach (FIG. 7) both fail. That is an argument against two specific naïve implementations — it is not an argument against P2's pairwise-aggregated-cost abstraction, which avoids the FIG. 7 failure (P2 advertises one aggregated cost per grouping pair, not contradictory per-neighbor costs). Far from rebutting the combination, the patent's own critique of FIG. 7 is a roadmap to the P2-style fix that a POSITA would have recognized.

Combination 2: N1/N2 + N3 alone, with the aggregation limitation argued as an obvious design choice

Even without P2, the "limited intra-area cost" limitation is arguably obvious because OSPF already implements area abstraction: the ABR's Network Summary LSA (RFC 2328 §12.4.3) advertises reachability to destinations outside the area using a single aggregated metric, precisely so that intra-area detail is not propagated. Motivation = [rationale (C)/(E): applying a known abstraction (OSPF summary LSA) to the SDN controller; "obvious to try" the same summary mechanism to hide intra-area detail]. This is a weaker theory than Combination 1 (summary LSAs summarize prefixes, not border-node pairs), but it is a genuine fallback and it is grounded in the reference the examiner already cited.

Combination 3: Combination 1 + P1 (US 2006/0092940 A1, Ansari)

P1 is the only patent reference that squarely predates priority but remains unverified this session. If P1 discloses separated control/forwarding or distributed routing (as its co-citation history in the ForCES/autonomic-router literature suggests), it becomes an additional § 103 component for the architecture preamble only — nothing more. I cannot chart it without the document. Flagged as a verification dependency, per the standing rule.

5. The dependent claims

Each dependent claim carries the claim-1 / claim-10 preamble, so it falls with its independent claim plus the additional teaching below.

Claim 4 / claim 13 is the hardest dependent claim, because it most specifically recites the border-pair shortest-path cost carried in an LSA. That is where P2 does the most work. If a tribunal rejects the motivation to port P2's ALTO-layer abstraction into an OSPF LSA, claims 4 and 13 are the survivable ones.

Backward-compatibility limitation (spec./claim-adjacent: "looks like N routers," sending N Hello / N Router-LSA packets per traditional process): this is a design requirement (interoperate with legacy routers) implemented with standard OSPF message formats — a known technique to achieve a known objective → [rationale (C)]. It weighs toward obviousness, not away, because the goal (interop) is stated and the means (mimic N routers with standard packets) is the conventional way to meet it.

6. Non-obviousness counterarguments (and why they are weak, but not frivolous)

A competent patentee (Ericsson) would press the following; a candid analyst must acknowledge them.

1. No reference literally discloses "advertise the intra-area shortest-path cost between border-switch pairs as an OSPF link." True. The case rests on a combination plus articulated motivation, not on a single reference. This is the patent's real (and only strong) defense: it forces the challenger to prove motivation, which is where § 103 cases are won and lost.
2. Different layer/protocol (P2 is ALTO, application-layer). Counter: the problem and the abstraction are the same, and KSR permits combining references from analogous fields where the technique is applied for the same purpose (hiding internal topology while enabling cost-based selection). ALTO and IGP routing are plainly analogous (both are routing-information-distribution mechanisms).
3. "Teaching away" — OSPF's area design deliberately withholds intra-area detail. This is the closest thing to a genuine teaching-away argument, but it cuts the other way: the claim does not propagate all internal costs; it propagates only an aggregated pair cost, which is consistent with (not contrary to) the OSPF area philosophy. There is no reference that says "do not advertise any aggregated intra-area cost."
4. Secondary considerations. There are none of record: no unexpected results, no long-felt-but-unsolved need tied to a specific claim element, no industry praise/copying, no commercial-success nexus, and — per the Litigation/PTAB sections — no assertion, no license, no adoption evidence. Absence of secondary considerations does not prove obviousness, but it removes the patentee's best rebuttal tool.
5. Hindsight risk. The combination is assembled from what the examiner already had — which helps the challenger (it defeats hindsight complaints) but also means the examiner considered and allowed over these references. § 325(d) discretion would be a real obstacle to a PTAB petition built on exactly this art, and a district-court challenger faces clear-and-convincing proof. The art the examiner cited does not include P2's pairwise-aggregation teaching being applied to OSPF — that is the space for a stronger (new) reference.

7. Bottom line

• Claim 1 and claim 10 (independent): A prima facie § 103 case is available under N1/N2 + N3 + P2. The pairing of OpenFlow (N1/N2) with OSPF (N3) is strongly motivated, and P2 supplies the express "aggregate into groupings / expose only pairwise costs" teaching that the patent calls its invention. The weaker, but still real, fallback is N1/N2 + N3 using OSPF's own summary-LSA abstraction [rationale (C)/(E)].
• Dependent claims 2, 3, 5, 6, 7, 8, 9, 11, 12, 14, 15, 16, 17, 18: obvious over the same combination plus N3/N1/N2 directly.
• Claims 4 and 13 (border-pair cost in an LSA): the battleground. Obvious if the P2 motivation is credited; the patent's best survival argument.
• Overall verdict: the claims are more likely than not obvious over the cited set once P2's verified disclosure is brought to bear — but this is a contested, motivation-dependent conclusion, not a certainty, and the strongest single-reference attack (claim 1 over N1/N2+N3 alone) requires arguing that OSPF's summary-LSA abstraction would obviously be repurposed to advertise border-pair costs.

Confidence: Moderate-to-High on the combinations and motivation; High on P2's identity, priority, and disclosure (verified this session); Unchanged that no § 102 anticipation exists on the face of the patent (Prior Art section stands).

8. Verification steps before relying on this in a filing/opinion

1. Pull US 2006/0092940 A1 (P1) by exact number — still unverified; it may add or subtract from Combination 3.
2. Retrieve the WO 2013/021304 A1 / EP 2742655 International Search Report — the EP front page says the EP report merely cross-references the WO report, so the WO ISR is the document that may cite art the U.S. front page omitted (Prior Art section flagged this).
3. Confirm the pre-AIA/AIA scope on the PatentCenter application data (priority 2011-08-11 ⇒ pre-AIA; the 2013-09-12 continuation filing date makes this worth a 30-second check).
4. Validate the P2 § 102(e) date against the actual published application's filing data (the provisional 61/418,793 of 2010-12-01 is the earliest US filing; confirm no intervening event).
5. If a § 103 challenge is contemplated, search for aggregation-of-intra-area-cost art beyond the examiner's set (OSPF/IS-IS area-aggregation, PNNI hierarchical/peer-group abstract topology, ATM Private Network-Network Interface summary cost) — this is the art that would most cleanly dispose of claims 4/13 and would not be subject to the § 325(d) headwind of re-using the examiner's references.

Sources: https://patents.google.com/patent/[US8976673](/patent/US8976673)/en (authoritative claim text) · https://patents.justia.com/patent/8976673 (Referenced Cited) · https://www.freepatentsonline.com/9413847.html and https://patents.google.com/patent/US20120144066 (P2 identity, priority, assignment, disclosure) · https://search-for-intellectual-property.service.gov.uk/EP2461547 (P2/EP counterpart owner = Juniper Networks, filing 2011-11-30) · RFC 2328 (Moy, OSPF v2, Apr. 1998) · N. McKeown et al., "OpenFlow: Enabling Innovation in Campus Networks," 2008-03-14 (N1) · "OpenFlow Switch Specification V1.1," 2011-02-28 (N2).