US 8559314

I'll search for this patent across USPTO and CAFC sources.

The searches returned unrelated results. Let me try more targeted queries.

Let me search specifically for CAFC litigation and any 2026 docket activity involving this patent.

Summary of US Patent 8,559,314 — verification notes first

Important caveat on sources. My only tool is a general web-search function; I could not query the USPTO PatentCenter, PACER, or the CAFC docket system directly. The bibliographic and claim content below is taken from the authoritative full patent text supplied in this task and corroborated by Google Patents, FreePatentsOnline, and Patents Encyclopedia. I found no authoritative evidence that US 8,559,314 is the subject of any CAFC 2026 appeal, despite running targeted docket searches (one search returned a nonprecedential CAFC order, General Access Solutions, Ltd. v. T‑Mobile USA, Inc., Ericsson, Inc., Nos. 2026‑1756, 2026‑1914, EDTX No. 2:23‑cv‑00158‑JRG, dismissed June 30, 2026 — but nothing in the retrieved text ties that case to patent 8,559,314, so I cannot assert a connection). Treat the litigation question as unverified.

Bibliographic data (per USPTO/Google Patents)

Abstract (as issued)

A method 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, remote from the switches providing the data plane, and facilitates optimized routing across the areas by providing limited intra-area link cost data to other controllers and to traditional routers — cost data giving the cost of each possible shortest-path traversal of the controller's area without providing all internal link cost data.

Plain-language overview of the independent claims

Claim 1 — Method (the core invention). A controller for one area of a split-architecture (SDN/OpenFlow-style) network:

1. Learns its area's topology, including every border switch (each border switch has at least one external port linking the area to another area or to a traditional router).
2. Computes the shortest path between each pair of border switches inside its own area.
3. Stores the cost of each such shortest path in a routing table.
4. Discovers neighbors — adjacent controllers and/or traditional routers — using a hello protocol.
5. Exchanges its link-state database with those neighbors, where the LSDB contains the per-border-switch-pair shortest-path costs (the "abstracted" intra-area costs).
6. Runs a shortest-path-tree computation over the whole network with the controller as root, using the link-state database.
7. Programs the forwarding tables of the switches in its area to match the shortest-path tree.

The inventive point (per the specification) is abstracting intra-area paths between border-switch pairs as direct "links" of known cost, so that every controller has enough information to compute a globally optimal end-to-end path, while avoiding both the sub-optimality of advertising external costs only and the contradictory-multiple-cost problem of per-neighbor internal-cost announcements.

Claim 9 — Network element / apparatus. Covers the same functionality in hardware terms: a network element acting as a controller, with:

• an ingress module and an egress module;
• a network processor executing a controller module (control-plane functionality), a topology learning module (determine area topology and border switches), a shortest path calculation module (find shortest paths between border switches and compute a network-wide shortest-path tree rooted at the controller using a link-state database), a neighbor discovery module (hello-protocol neighbor identification), and a link state management module (exchange the LSDB containing per-border-switch-pair shortest-route costs with neighbor controllers and traditional routers); and
• a routing table storage device storing routing tables including intra-area and inter-border-switch shortest-path information.

Dependent claims (brief)

Method (2–8): hello packets sent/received on external ports (2); LSAs advertising external-link costs (3) and per-border-switch-pair shortest-path costs (4); advertising updated link-status data (5) via LSA messages (6); updating switch forwarding tables via OpenFlow (7); initializing OSPF protocol data structures at the controller (8).

Apparatus (10–16): mirror images of 2–8 applied to the corresponding modules (neighbor discovery, link-state management, link status advertising, OpenFlow forwarding-table updates, OSPF data-structure initialization).

Uncertainty flags

• No verified CAFC 2026 docket for this patent was found; the General Access Solutions order involves Ericsson but its relationship to 8,559,314 is unconfirmed.
• The patent text contains internal errata (e.g., "RFC 23278" appears in one spot for RFC 2328; a few block numbers in the FIG. 10 discussion jump from 1009 to 1111/1113). These are reproduced literally and not auto-corrected.
• Expiration/"Active" status is the database's stated assumption and not a legal conclusion.

I'll research litigation involving US patent 8559314. Let me search multiple sources.

Let me search more targeted sources for this specific patent.

Let me search specific patent litigation databases and court records.

Litigation Search Results: US Patent No. 8,559,314

Bottom line: I found no litigation involving US Patent No. 8,559,314.

I searched for the specific number 8559314 / 8,559,314 across patent-litigation aggregators (Unified Patents litigation portal, RPX Insight, CourtListener/RECAP, PTAB/PTActions, CAFC-related dockets) and general web sources. None of the returned records identify this patent as being asserted in any district court, ITC, or PTAB proceeding. The hits I retrieved were for other patents (e.g., unrelated "…931" patents like Enzo's 5,190,931; Daignean's 8,576,803; and Ericsson's FRAND/SEP litigation over entirely different patents such as 6,301,556 and 6,473,506) and do not pertain to 8,559,314. I did not auto-substitute any neighboring numbers.

Patent identity (for confirmation)

• Patent: US 8,559,314 B2 — "Implementing OSPF in split-architecture networks"
• Assignee/Owner: Telefonaktiebolaget LM Ericsson (publ)
• Inventors: Kiran Yedavalli; Neda Beheshti-Zavareh; Ying Zhang
• App. No.: 13/208,251; Priority/Filing: 2011‑08‑11; Granted: 2013‑10‑15
• Continuation: US 8,976,673 B2 (from App. 14/025,477) shares the same family/specification
• Source: https://patents.google.com/patent/US8559314/en

Litigation details

No plaintiff, defendant, jurisdiction, case number, filing date, or outcome can be reported because no case records were located.

Important caveats (please read as a limitation, not a clean bill of health)

1. My research was cut short by tool limits — I was unable to complete the planned follow-up queries (directly querying the Unified Patents case list, RPX Insight's patent page for 8,559,314, Docket Navigator, and PACER for the patent number). A negative result here is not proof that no suit exists.
2. This patent is a networking/infrastructure patent owned by Ericsson, a large operating company rather than a litigation-focused NPE. Patents of this kind are less likely than SEPs or NPE portfolio patents to appear in public infringement suits, which is consistent with finding no cases — but it does not confirm none were filed.
3. Ericsson's well-documented North American patent litigation (e.g., Ericsson v. TCL, Ericsson v. Apple, the Wi‑LAN and Adaptix matters, and the various FRAND disputes) concerns different patents. Nothing in those records ties 8,559,314 to any asserted claim chart.
4. Some searches for "…314" returned patents such as 8,576,803, 8,583,100, and 8,497,813; these are not US 8,559,314 and should not be conflated with it.

Recommended verification steps

To reach a defensible conclusion, I would confirm against, at minimum:

• Unified Patents litigation case list: https://portal.unifiedpatents.com/litigation/caselist (search by patent number)
• RPX Insight patent page for 8,559,314
• PACER / CourtListener docket search for "8,559,314" and "8559314"
• USPTO PTAB (PTAB Center) for any IPR/PGR involving 8,559,314
• CAFC docket search for the patent number

If you'd like, I can attempt these targeted lookups again (subject to the step limit) so the negative finding is more robustly sourced.

Confidence statement: I have low-to-moderate confidence in the negative result given the incomplete tool run. I do not know of any litigation involving US 8,559,314, and I found none in the searches performed — but I cannot affirmatively certify that no litigation exists.

PTAB / AIA Trial Proceedings — US 8,559,314

Patent: US 8,559,314 B2 ("Implementing OSPF in split-architecture networks")
Assignee of record: Telefonaktiebolaget LM Ericsson (Publ)
Appl. No.: 13/208,251 · Filed: 2011-08-11 · Granted: 2013-10-15 · Adjusted expiration: 2032-01-02
Continuation in family: US 8,976,673 B2 (from 14/025,477, filed 2013-09-12)
Sources consulted: USPTO ODP structured PTAB-proceedings block (canonical list supplied with this task); PTAB E2E; Google Patents US8559314B2; Justia Patents; CourtListener; open web search.

Proceedings overview

Total AIA trial proceedings on file: 0. The structured USPTO Open Data Portal block returned no IPR, PGR, or CBM proceedings against US 8,559,314, and independent web searching surfaced no petition, institution decision, Final Written Decision, or Federal Circuit appeal naming this patent — meaning all 16 claims (independent claims 1 and 9 plus dependents 2–8 and 10–16) are UNTESTED at the PTAB, and no claim has been canceled; the bottom-line defensive posture is that this patent is unattrited but also unchallenged — a defendant cannot point to a PTAB kill, but equally has no estoppel-laden roadmap handed to it, and the absence of any IPR is a meaningful signal that the patent has not been heavily commercialized in litigation.

There are therefore no per-proceeding entries to report. I flag below the near-miss hits I encountered so that no one mistakes them for proceedings against this patent.

Near-miss items reviewed and excluded (NOT proceedings on '314)

• IPR2015-01602 / -01637 / -01641 / -01646 / -01674 / -01676 / -01761 / -01806 (TCL Corp. et al. v. Telefonaktiebolaget LM Ericsson), U.S. Patent No. RE43,931 E — a large Ericsson-owned patent family under PTAB attack, but a different patent. Final Written Decision in IPR2015-01806 (Paper 36, entered 2017-02-01) held claims 58–69 of RE43,931 unpatentable. Panel: APJs Patrick R. Scanlon, Barbara A. Benoit, Stacy B. Margolies. This is relevant only as pattern evidence about the patent owner's PTAB experience — not as a challenge to '314.
• IPR2016-01484 (Telefonaktiebolaget LM Ericsson and Ericsson Inc. v. Cellular Communications Equipment LLC), U.S. Patent No. 9,025,590 — Ericsson here is the petitioner, not the owner. Unrelated patent.
• CourtListener bankruptcy notice (Case 25-40712, Bankr. E.D. Tex., filed 2025-04-05) — a creditor/mailing-list schedule containing the string "8559314" next to a German address. This is a coincidental numeric match in a bankruptcy notice, not a patent proceeding. Disregard it.
• PTAB E2E / PTActs petition documents containing "2559314"-adjacent strings, §§ 314(a), 315(e), Fintiv and Sotera discussions — general Board practice documents returned by keyword noise; none concerns '314.

Strategic summary

Claim status for US 8,559,314. Every claim is UNTESTED. Independent claim 1 (method: learn topology of a split-architecture area, compute shortest path between each border switch pair, store those costs, discover neighbors via a hello protocol, exchange a link state database containing those border-pair shortest-path costs, compute a shortest path tree with the controller as root, and program the area's forwarding tables) stands untouched. Independent claim 9 (the network-element counterpart: ingress/egress modules, network processor executing topology-learning, shortest-path-calculation, neighbor-discovery and link-state-management modules, plus a routing table storage device) likewise stands. Dependents 2–8 and 10–16 — including the OpenFlow-specific claims 7 and 15 and the OSPF-data-structure-initialization claims 8 and 16 — also stand. There has been no certificate of cancellation, no disclaimer, and no ex parte reexam-driven amendment that I could locate.

Estoppel landscape. Because no IPR has reached a Final Written Decision against this patent, § 315(e)(2) estoppel has not attached against anyone with respect to '314. A defendant today may raise any § 102/§ 103 ground, on any prior-art patent or printed publication, in district court or in a fresh IPR — with two caveats worth pricing in: (i) if you or your privies file your own IPR and it reaches FWD, you will be estopped from relitigating in court the grounds you raised or reasonably could have raised; and (ii) the General Plastic / § 314(a) follow-on discretionary-denial line of cases (illustrated in the PTAB practice documents surfaced in my search) does not bite here because there is no earlier petition on this patent by anyone. The practical corollary: the first mover gets the cleanest shot. Prior art considered but not applied during prosecution of 13/208,251 and its PCT sibling PCT/IB2012/053833 (published as WO 2013/021304 A1) is fair game.

Pattern signals. Ericsson behaves as a sophisticated, two-sided PTAB participant — it has been a serial patent owner in front of the Board (the RE43,931 cluster, seven-plus IPRs) and a serial petitioner (e.g., IPR2016-01484 against Cellular Communications Equipment). The company has also litigated its split-architecture portfolio (the controller-placement family including US 8,804,490 and US 9,059,928 appears in the '314 citation network, and Ericsson appears as a party in E.D. Tex. patent actions in the 2024–2025 window per the PTActs materials returned in search). None of that, however, produced any challenge to '314. No defensive aggregator (Unified Patents, RPX, etc.) appears in the chain for this patent, and there is no evidence of a hedge-fund-funded IPR campaign against the Ericsson split-architecture portfolio. The refusal of the market to IPR this patent is consistent with a patent that was filed 2011-08-11, granted 2013-10-15, and is largely a standards-adjacent protocol-modification disclosure rather than a litigation-grade assertion vehicle.

Forward-looking caveat. A zero-result ODP block plus negative web search is strong but not metaphysical proof of absence. PTAB filings sometimes lag ODP ingest, and a very recently filed petition may not yet be indexed. Verify directly before relying on this in a brief.

Recommended next steps

1. Verify the null result at the source, dated. Run the patent number through PTAB E2E (https://ptacts.uspto.gov/ptabweb/) and the ODP API and print the search date into your work product. Also check the continuation US 8,976,673 independently — a challenge there would not appear under '314's number even though it shares the 2011-08-11 priority date, and the two patents are near-identical in claim scope. I found no IPR against US 8,976,673 either, but treat that as a lower-confidence finding than the '314 result.

2. Because no proceeding exists, there is no FWD to link and no disposition to quote. Do not manufacture one. If you are drafting a notice-letter response or an invalidity contentions chart, the correct statement is: "As of the search date, US 8,559,314 has not been the subject of any IPR, PGR, or CBM proceeding; no claim of the patent has been canceled or held unpatentable by the PTAB." Cite the Google Patents page (https://patents.google.com/patent/US8559314B2/en) and Justia (https://patents.justia.com/patent/8559314) as showing no PTAB/litigation linkages, and attach your own E2E screenshot.

3. Build the invalidity case from scratch, and fast. The absence of prior IPRs means no one has done your § 102/§ 103 homework. Priority date is 2011-08-11 (post-AIA filing date, but pre-AIA rules apply for a § 102 analysis given the 2011 filing — confirm the AIA/pre-AIA treatment claim by claim). The claim 1 limitation that is likely to be the crux is the "limited intra-area link cost data … costs of each possible shortest path traversal of the area of the controller without providing all internal link cost data" abstraction, i.e., abstracting border-switch-pair shortest-path costs as a direct link. That is squarely in the space of prior OSPF area-abstraction and PNNI/MPLS "abstract link" / aggregated-metric work and of contemporaneous OpenFlow/NOX and OpenDaylight-adjacent publications; RFC 2328 itself (type-3 summary LSAs, area abstraction) is an obvious starting exhibit.

4. Consider a first-filer IPR strategically. With no prior petition, a petitioner faces no General Plastic follow-on risk and no § 315(e)(2) estoppel until its own FWD issues. If litigation is pending or threatened, weigh a Sotera-style stipulation to defeat a Fintiv discretionary denial — the Board's binding guidance (relied on in the PTActs materials surfaced here) is that the PTAB "will not discretionarily deny institution … where a petitioner presents a [Sotera] stipulation." If you institute, the statutory clock is firm: FWD due within one year of the institution notice under § 316(a)(11).

5. If you are instead advising the patent owner, the practical read is that '314's ~2032 term and zero PTAB history make it a viable but untested assertion asset. Expect any real assertion campaign to draw a first-ever IPR almost immediately — the first defendant with a budget will file, because the follow-on-petition bar will be low and the patent is materially identical to its own continuation.

I'll start by verifying the assignment record against the primary sources before writing anything.

Key finding already. Let me verify the reel/frame and check for any downstream transfers.

Let me verify the reel/frame on USPTO-side sources and check for litigation/assertion activity.

US 8559314 B2 — Ownership Chain Analysis

"Implementing OSPF in split-architecture networks" · App. 13/208,251 · Filed 2011-08-11 · Issued 2013-10-15 · Assignee of record: Telefonaktiebolaget LM Ericsson (publ)

Source note / limitation: I was able to retrieve the reel/frame for this patent from the Google Patents legal-events feed for the family, but I could not complete a direct interactive query against assignmentcenter.uspto.gov or assignment.uspto.gov/patent/index.html in this session. The reel/frame below is quoted verbatim from the machine-readable assignment event. The correspondent of record was not retrievable and is reported as unknown rather than guessed.

Inventors

All three are the only assignors on the sole recorded assignment, and all three list the same Ericsson Research location (per the printed front pages of the sibling patents in this family). This is an ordinary corporate R&D team filing.

Departure pattern: Unclear — not determinable from available records. I found no evidence that any of the three inventors left Ericsson within 12 months of filing, and I decline to infer it. Note that none of the three appears as an assignor on any later assignment for this patent, but that is unremarkable given there are no later assignments at all. The presence of inventor Joel Halpern (Leesburg, VA) on the sibling controller placement patent but not on this one is a normal team-composition difference, not a signal.

Original assignee

Telefonaktiebolaget LM Ericsson (publ), Stockholm, Sweden (recorded as "TELEFONAKTIEBOLAGET L M ERICSSON (PUBL)").

• Product embodying the claims: Yes — this is core Ericsson carrier-grade networking R&D. The patent describes SDN/OpenFlow split-architecture control plane routing (OSPF with abstracted intra-area path costs) for the access/aggregation domain, mobile backhaul, and multilayer transport. Ericsson commercialized split-architecture / SDN-enabled control of its transport and mobile-backhaul portfolio in this era. The claimed subject matter is implementation-level OSPF for a centralized controller — squarely a vendor product feature, not a licensing abstraction.
• Primary line of business: Telecommunications network infrastructure (radio access, transport, core, and network management) plus a large SEP licensing program covering 2G/3G/4G standards.
• Current status: Operating. Publicly listed (Nasdaq Stockholm: ERIC; Nasdaq New York: ERIC). Not in bankruptcy. No reorganisation affecting this patent.
• Maintenance: Maintenance fees paid — 4th year (event code M1551) and 8th year (event code M1552), both recorded "LARGE ENTITY" with entity status of patent owner = large entity. A certificate of correction is also recorded. These events are inconsistent with abandonment or a distressed transfer.

Assignment timeline

There is exactly one recorded assignment in the chain. It is the routine inventor-to-corporate-employer assignment.

• 2011-08-11 (executed / effective) / recorded date not retrieved — Reel 034802/0202
  • Conveyance: Assignment (ASSIGNMENT OF ASSIGNORS INTEREST)
  • Assignor: Yedavalli, Kiran; Beheshti-Zavareh, Neda; Zhang, Ying (all three inventors, jointly)
  • Assignee: Telefonaktiebolaget L M Ericsson (publ), Stockholm, Sweden
  • Correspondent: Not retrieved. The assignment record's correspondent-of-record field was not surfaced by the sources I could reach. I am flagging this as an open item rather than fabricating a name. (If a single repeat-player attorney were running a shell chain here, this is where you would look — but on this record there is no shell chain for them to run.)
  • Context: Internal reorg / standard employment assignment — inventors conveying their rights to their employer on the filing date. Not an acquisition, not a fire-sale, not a securitization, not a transfer-to-asserter.
  • ⚠️ Date conflict, flagged: Google Patents' "Reassignments" table for US 8,559,314 separately dates this as 2011-08-12, while the legal-events AS record gives effective date 2011-08-11 at reel 034802/0202. The reel block (034802) is numerically consistent with a recording in the late-2014/early-2015 range, i.e. a late-recorded confirmatory assignment, not a 2011 recording. I cannot resolve this from the sources available and am not asserting a recording date.

Continuation (same owner, no new conveyance): US 14/025,477, filed 2013-09-12, issued 2015-03-10 as US 8,976,673, "Implementing OSPF in split-architecture networks." Same assignee, same inventors. A continuation is not an assignment event, but it matters because the family's legal-events feed is where reel 034802/0202 surfaces.

No post-issuance transfer of any kind exists. No transfer to an IP-holding LLC, no security agreement, no license recordation against the patent, no release, no merger.

Timeline diagram

timeline
    title Ownership of US 8559314
    2011 : Three inventors assign to Ericsson
         : Application filed 11 Aug
    2013 : Patent issued 15 Oct
         : Continuation US 14/025,477 filed
    2015 : Continuation issues as US 8976673
    2021 : Eighth year maintenance fee paid

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT. No assignment to any "IP / Patents / Licensing / Holdings / Ventures" entity. The only recorded assignment runs into the operating parent, not out of it, at reel 034802/0202. There is no single-member LLC anywhere in the chain to test for a registered-agent address.

2. Known asserter in the chain — NOT PRESENT. Neither the assignor nor the assignee matches any entity on the Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, or Spangenberg rosters. Ericsson is a practicing manufacturer and a standards-essential licensor — a very different posture from an NPE, and it does not appear on Unified Patents or RPX high-frequency-plaintiff lists.

3. Repeat correspondent across the chain — NOT PRESENT (single link only). There is only one recorded assignment, so recurrence is arithmetically impossible. Correspondent not retrieved — flagged above. A single appearance would not be a finding under the stated rule anyway.

4. Cascading transfers — NOT PRESENT. Zero post-issuance assignments. There is no chain of LLCs, no shared correspondent address, no common principals, nothing to cascade. The chain terminates where it started.

5. Pre-litigation transfer — NOT PRESENT. No assignment dated within 6 months before any suit. The only assignment predates the 2013-10-15 issue date by more than two years (effective 2011-08-11) and is the original employment assignment. I also found no infringement action naming US 8,559,314 at all. Ericsson's public campaigns (e.g. Ericsson v. TCL, Ericsson v. Micromax/Intex/Xiaomi/Gionee in India, the E.D. Tex. actions) assert cellular SEPs and unrelated patents — US 8,559,314, an SDN/OSPF routing patent, is not among the asserted patents-in-suit I could identify. Absence of assertion is itself the finding here.

6. Bankruptcy fire-sale — NOT PRESENT. Ericsson has not filed Chapter 7 or 11. No bankruptcy docket, no §363 sale, no assignment out of an estate. Contrast the Kodak/Nortel/Polaroid pattern — none of that applies.

7. Privateering — NOT PRESENT. No transfer to an NPE asserting on Ericsson's behalf. Ericsson asserts its own patents in its own name (and via Ericsson Inc.), which is the opposite of privateering. Note that Ericsson's SEP licensing program is aggressive and heavily litigated — TCL, HTC, the Indian SEP cases — but that is direct operating-company assertion, and it does not involve this patent.

8. Defensive aggregator (anti-NPE) — NOT PRESENT. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. The patent remains with the original operating company. (This signal would be absent rather than "neutral" — the patent has not been neutralized by a defensive aggregator; it simply was never sold.)

Verdict

Insufficient data (chain consists of the original assignment only).

The entire recorded ownership history is a single inventor-to-employer conveyance at reel 034802/0202, effective 2011-08-11, from Yedavalli, Beheshti-Zavareh, and Zhang to Telefonaktiebolaget LM Ericsson (publ) — followed by maintenance fees paid at the 4th and 8th years as a large entity. There is no post-issuance transfer, no NPE anywhere in the chain, and no litigation naming this patent that I could identify, so not one of the eight NPE signals lands as "present." The finding is a clean, unbroken operating-company chain; if a future transfer ever occurs, the party to scrutinize first is whoever is listed as correspondent on that new record, since the present record's correspondent is still unretrieved.

Verification links:

• USPTO Assignment Center (search patent 8559314): https://assignmentcenter.uspto.gov/
• Indexed assignment search: https://assignment.uspto.gov/patent/index.html
• Google Patents record with legal events / reassignments: https://patents.google.com/patent/US8559314/en
• Continuation family member (where reel 034802/0202 is displayed): https://patents.google.com/patent/US20140016477

Open items I could not close: (1) the correspondent of record on reel 034802/0202; (2) the exact recording date (the 2011-08-12 vs. effective-2011-08-11 discrepancy); (3) confirmation whether a separate earlier-recorded assignment exists in addition to reel 034802/0202.

I'll search for the specific patent and its cited prior art references.

Let me retrieve the front-page citation lists for US8559314 specifically.

Let me get the complete front-page reference list from additional sources.

Analysis of US 8,559,314 B2 — "Implementing OSPF in split-architecture networks"

Important preliminary caveat on data limits. My searches returned the Google Patents full text (the version you supplied) and secondary mirrors (Justia, FreePatentsOnline, EPO DOCDB). The Google Patents rendering I retrieved did not include the rendered "Patent Citations" (backward-citation) table — only the "Cited By" and "Families Citing" tables. The only backward-citation list I could retrieve is the truncated one on Justia (https://patents.justia.com/patent/8559314), which displays only the first and last U.S. Patent Documents with an ellipsis between them. I therefore cannot certify that the list below is exhaustive, and I have flagged every item whose full identity I could not verify. Per your strict rule, I am not filling gaps with reconstructed or assumed content.

1. Patent under analysis (bibliographic, per the authoritative full text)

Claim 1 (independent) — element breakdown used for the § 102 mapping below:

1. A network element functioning as one of a plurality of controllers for one of a plurality of areas of a split architecture network, providing a remote control plane for switches;
2. providing limited intra-area link-cost data = "costs of each possible shortest path traversal of the area" without all internal link-cost data;
3. learning the area topology including each border switch having ≥1 external port;
4. computing a shortest path between each border-switch pair;
5. storing the cost of each such shortest path in a routing table;
6. identifying each neighbor controller/router via a hello protocol;
7. exchanging a link-state database with each neighbor, the LSDB including the cost of each shortest path between each border-switch pair;
8. calculating a shortest-path tree for the network with the controller as root (using the LSDB);
9. updating forwarding tables in the area's switches accordingly.

2. Backward citations (references cited in / against US 8,559,314) — the "most relevant prior art"

2.1 U.S. Patent Documents

(A) US 2006/0092940 A1 — Ansari et al. — published May 4, 2006

• Full citation as listed: US 2006/0092940 A1, "Ansari et al.," published 2006-05-04.
• Confidence on content: LOW. I could retrieve the citation string and date but not the title/abstract within my search budget. I will not assert a title. (A frequently cited document matching this number/date/inventor is in the distributed-router / control-element–forwarding-element separation field, but I am not treating that as verified.)
• Potential § 102 relevance: Given the split element of claim 1 (element 1 — control plane physically separated from forwarding elements), a "distributed router / separated control-and-forwarding element" reference is the class of art that would be mapped to the preamble and element 1 of claim 1 and to claim 9 (ingress module / egress module / network processor / controller module). It would not reach the distinguishing elements 2, 4, 7 (the border-switch-pair cost abstraction). Verify the title and abstract before relying on this.

(B) US 2012/0144066 A1 — Medved et al. — published June 7, 2012

• Full citation as listed: US 2012/0144066 A1, "Medved et al.," published 2012-06-07.
• Confidence on content: LOW. Citation string and date only. Title/abstract not verified.
• Timing note (this matters): Publication 2012-06-07 post-dates the 2011-08-11 filing/priority date. It can therefore only be § 102(a)(2)/§ 102(e) art if its effective filing date predates 2011-08-11 — which must be confirmed from the document itself. It cannot be § 102(a)(1)/§ 102(b) printed-publication art against this patent.
• Potential § 102 relevance: A centralized/SDN controller reference would be mapped to claim 1 element 1 and claim 9's "controller module." Likely only relevant to the preamble/architecture elements.

Truncation warning: Justia's list shows only these two U.S. documents. A granted Ericsson patent of this type typically cites on the order of a dozen or more U.S. patent documents (e.g., SoftRouter-family and split-plane references). Treat § 2.1 as incomplete.

2.2 Non-Patent Citations (these I can describe with confidence)

(C) J. Moy, "OSPF Version 2," RFC 2328, Network Working Group, April 1998, 204 pages.

• Date: April 1998 → printed publication well before the 2011 priority date; § 102(b) (pre-AIA) / § 102(a)(1) art.
• Description: The normative OSPF specification. Discloses: areas and Area Border Routers; hello protocol for neighbor discovery and adjacency maintenance; flooding of Link State Advertisements; the link-state database; per-router shortest-path-tree calculation with the router as root via Dijkstra; and the five OSPF packet types (Hello, Database Description, Link State Request, Link State Update, Link State Ack).
• Claims potentially anticipated (if read alone or with the split-architecture preamble supplied elsewhere):
  • Claim 2 (send hello packets on each external port / receive hello packets from each neighbor) — the OSPF Hello protocol is squarely disclosed.
  • Claim 3 (LSA including the cost of each external link) — OSPF Router-LSA interface-cost advertisements.
  • Claim 5 and claim 6 (advertising updated link status via LSA) — routine LSA flooding on state change.
  • Claim 8 (initializing OSPF protocol data structures at the router) — describes the OSPF process initialization.
• Does it anticipate claim 1? No. RFC 2328 is a single-router link-state protocol; it does not disclose a remote controller providing the control plane for a set of switches ("split architecture"), nor the border-switch-pair cost abstraction of element 2/7, nor controller-driven forwarding-table programming (element 9). It is best characterized as § 103 background art, not § 102 anticipating art for claims 1 or 9.

(D) N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, J. Turner, "OpenFlow: Enabling Innovation in Campus Networks," March 14, 2008, 6 pages (cited via www.openflowswitch.org).

• Date: 2008-03-14 → § 102(b) art.
• Description: Introduces OpenFlow: a remote controller communicating with switches over a secure channel, populating flow tables with match/action rules. Establishes the control-plane/data-plane separation this patent builds on.
• Claims potentially relevant: Claim 7 ("updating forwarding tables of each switch in the area of the controller using the OpenFlow Protocol") and the claim 9 "controller module." Element 1 (remote controller vs. switches) is also disclosed.
• Does it anticipate claim 1? No — no OSPF, no border-switch-pair cost abstraction, no LSDB exchange among area controllers.

(E) "OpenFlow Switch Specification V1.1," http://openflow.org/documents/openflow1.1-allmerged-draft2.pdf, February 28, 2011, 56 pages.

• Date: 2011-02-28 → predates the 2011-08-11 filing; § 102(b) art.
• Description: Wire specification for the controller–switch protocol, flow-table configuration and the secure channel.
• Claims potentially relevant: Claim 7 and the apparatus-side control module in claim 9. Companion art to (D).

(F) "Open Shortest Path First," Wikipedia (http://en.wikipedia.org/wiki/Open—Shortest—Path—First), 14 pages, retrieved 2011.

• Date: retrieval stated as 2011; publication date on the face of the document is what governs. Likely § 102(b) art.
• Description: Encyclopedic summary of OSPF (link-state operation, areas, Dijkstra). Generic background.
• Claims potentially relevant: None independently; supports the "well-known OSPF" narrative behind claims 2, 3, 5, 6, 8. Not an anticipating reference.

3. Forward citations ("Cited By," per the authoritative full text) — not § 102 prior art

These post-date the 8,559,314 priority date and therefore cannot anticipate claims 1–16 (they are relevant only to freedom-to-operate/landscape analysis):

One item deserves a flag: the first two entries (US 2013/0028070 A1 and US 8,804,490 B2) carry a priority date of 2011-07-29, which is 13 days earlier than the 8,559,314 priority date of 2011-08-11. They are Ericsson sibling filings. Because their effective filing dates precede the subject patent's date, they are technically candidates for § 102(a)(2) art — but neither is directed to the intra-area border-switch cost abstraction that distinguishes claim 1, so neither would anticipate. (Whether they might be § 103 combinable art is a separate question, and common ownership/Ericsson-family status would bear on that analysis.)

4. Overall § 102 assessment

Bottom line: no reference in the retrieved citation set anticipates claim 1 or claim 9.

• Claim 1 / claim 9 are not anticipated. The novelty of claim 1 does not lie in OSPF itself (RFC 2328, element 6/7/8 partially), nor in the split architecture (McKeown/OpenFlow — element 1/9), nor in any single one of the cited references. It lies in the combination recited in the "limited intra-area link cost data" limitation — abstracting the intra-area path cost between every pair of border switches as a direct link, propagating only that aggregated cost in the LSDB, and thereby enabling per-controller optimal SPT computation without distributing all internal link costs. No located reference discloses that abstraction. On the present record, the strongest challenge to claim 1 would be a § 103 obviousness case built from RFC 2328 + an OpenFlow/split-architecture reference — not § 102.
• The dependent claims are where § 102 bite exists — but only with a caveat. Claims 2, 3, 5, 6 and 8 read on ordinary OSPF behavior disclosed in RFC 2328, and claim 7 reads on OpenFlow (McKeown 2008; OpenFlow Switch Spec V1.1). However, because each depends from claim 1, a § 102 rejection would still require the primary reference to teach every claim-1 limitation, which none does. These references are therefore best deployed as § 103 art against the dependent claims, or as evidence of the state of the art underlying the "prior art" discussion in the patent's own Background (which expressly concedes the external-cost-only approach of Fig. 6 and the full-internal-cost approach of Fig. 7).
• The two U.S. patent documents (Ansari 2006/0092940; Medved 2012/0144066) are, on their face, preamble/architecture-level art. Neither is positioned to anticipate the distinguishing limitation; and I could not verify their subject matter within my search budget, so no § 102 assertion should be made about them without pulling their face pages.

5. Limitations and recommended next steps

1. The backward-citation list is incomplete as retrieved. To give you a certifiable "each patent citation" answer, the full "Patent Citations" table must be pulled from the USPTO PatentCenter / Patent Full-Text (PATFT) record or the PDF face page (patentimages.storage.googleapis.com/.../US8559314.pdf), the EPO register entry for the family member EP 2 742 655 B1, or the PCT search report for WO 2013/021304 A1 (PCT/IB2012/053833) — the latter will contain the examiner's cited art with relevance categories (X/Y/A).
2. Verify titles/abstracts for US 2006/0092940 A1 and US 2012/0144066 A1, and confirm the effective filing date of US 2012/0144066 A1 before treating it as § 102(a)(2) art.
3. The continuation US 8,976,673 B2 (from US 14/025,477, filed 2013-09-12, same priority 2011-08-11) has its own citation record; it should be searched separately, since a continuation's cited art often differs from the parent's.
4. Anticipation/obviousness conclusions here are analytical, not legal opinions, and the post-AIA § 102 framework (effective filing date 2011-08-11 falls after the 2013-03-16 AIA date? — no: 2011-08-11 predates the AIA first-inventor-to-file effective date of 2013-03-16, so pre-AIA § 102 applies, meaning § 102(a)/(b)/(e) and the § 102(g) and 35 U.S.C. § 103(a) frameworks govern).

Sources: Google Patents https://patents.google.com/patent/US8559314B2/en (full text provided); Justia https://patents.justia.com/patent/8559314 (truncated citation list); EPO DOCDB record for EP 2742655 A1 / WO 2013/021304 A1 (http://data.epo.org/pise-server/rest/collections/lgpi/EP2742655A1.pdf); FreePatentsOnline records for US 8,804,490 and class 370/255.

I'll ground the prior-art references before building the §103 analysis.

The search surfaced the examiner's actual "Referenced Cited" list. Let me pin down those two patent references and the Ericsson prior work.

Obviousness Analysis — US 8,559,314 B2 (35 U.S.C. § 103)

0. Note on the "Prior Art" inputs actually available

Two clarifications before the analysis, per the operating rules:

• The Google Patents page supplied does not contain a traditional "References Cited" (prior-art-of-record) section. Its only "prior art" content is the keyword cloud (controller, area, network, link, shortest path) and the "Prior art date 2011‑08‑11." The entries under "Cited By" and "Families Citing this family" postdate the 2011‑08‑11 priority date and therefore are not §102/§103 prior art (e.g., Brocade 2014–2015, Huawei 2013, Google 2013). I flag this because the task said to use "the results from the Prior Art section of this page" — that section is effectively empty of references.
• The examiner's actual cited references are recoverable from the Justia record for this patent (patents.justia.com/patent/8559314), which lists: US 2006/0092940 A1 (Ansari et al., May 4, 2006); US 2012/0144066 A1 (Medved et al., June 7, 2012); N. McKeown et al., "OpenFlow: Enabling Innovation in Campus Networks" (Mar. 14, 2008); OpenFlow Switch Specification v1.1 (Feb. 28, 2011); J. Moy, "OSPF Version 2," RFC 2328 (Apr. 1998); and a Wikipedia OSPF entry (retrieved 2011). Source: https://patents.justia.com/patent/8559314

The analysis below builds on those of-record references plus contemporaneous non-patent literature I verified in search (citations and dates given inline). Where I could not verify a reference's content, I say so rather than filling the gap.

1. Governing law and posture

• Pre‑AIA § 103(a) applies. The application was filed August 11, 2011, before the AIA first‑inventor‑to‑file effective date of March 16, 2013. So the inquiry is whether "the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art." Prior art must qualify under pre‑AIA § 102(a)/(b)/(e).
• KSR Int'l v. Teleflex (2007) governs: a combination of known elements is obvious where (i) the elements were known in the field, (ii) there was a known problem for which each element provided a known solution, and (iii) a POSITA had a reason to combine with a reasonable expectation of success. Obvious to try and "predictable variation" doctrines apply.
• Note the specification's own admissions are usable as prior-art/background characterizations. The Background section expressly describes two prior split-architecture OSPF schemes: (a) "ignore the internal costs and only exchange information about external costs" ("each Split Architecture area can be considered as a single node"), and (b) "including the internal costs in the information exchanged between controllers" (adding the border-switch shortest-path cost to the announced inter-area cost). Both are admitted known approaches.

2. Person having ordinary skill in the art (POSITA)

A POSITA here would hold a B.S. in CS/EE (or equivalent) and ~2 years' experience in IP networking, including link-state routing (OSPF per RFC 2328) and/or centralized/split control-plane architectures (ForCES/OpenFlow). This is consistent with the level articulated in comparable networking IPRs (e.g., a "bachelor's degree in computer science or computer engineering… and at least two years of work experience in the field of computer networking," per the NetApp petition discussed at ptacts.uspto.gov, Artifact 1540165).

3. Claim 1 — element-by-element mapping

Observation: every step in claim 1 is a conventional OSPF procedure (per Moy) or a conventional split-architecture operation (per OF/ForCES/Ansari), with the single arguable point of novelty being the granularity/aggregation of the advertised intra-area costs ("cost of each shortest path between each border switch pair"). That limitation is addressed in §5.

4. The combinations, and the reason to combine

Combination A (strongest): Moy (RFC 2328) + McKeown/OpenFlow + Ansari '940 (SoftRouter)

Why motivated: OpenFlow and ForCES/SoftRouter already taught running routing/control logic on servers physically separated from forwarding elements; OSPF is the dominant intra-domain IGP. A POSITA tasked with giving a multi-area split-architecture network reachability compatible with the installed base of routers would, as a matter of ordinary design, run OSPF's control plane on the controller and exchange standard OSPF messages toward legacy routers. All three references are in the examiner's own cited list — the Office already treated this record as the relevant art.

Combination B: Moy + OpenFlow Spec v1.1 + Green/Kempf/Thorelli/Takacs, "MPLS, OpenFlow and the Split Router Architecture" (Ericsson Research, MPLS 2010)

This Ericsson presentation (https://fp7-sparc.eu/assets/documents/MPLS2010EMPLS-Openflow.pdf) discloses the "split router": "Control functions run as 'network applications' on centralized controller," with an OpenFlow controller performing "Topology Discovery and maintenance," "Path Computation and TE," and listing use cases explicitly including "Access Network / Aggregation Network / Core Net" and "Central control of aggregation region." It also cites FORCES. This is essentially the architecture of claim 9 (controller with topology-learning and path-computation modules) applied to an aggregation domain — the very field the patent names. Combining it with Moy to supply the OSPF protocol particulars is a textbook KSR combination.

Combination C: Moy + RouteFlow (Nascimento et al., CFI 2011)

RouteFlow virtualizes routing engines (Quagga/XORP running OSPF/BGP/IS‑IS) on a controller and "translates [the FIB] into OpenFlow tuples… installed in the associated OpenFlow-enabled devices" (https://openhub.net/p/routeflow; book chapter at https://www.dca.fee.unicamp.br/~chesteve/pubs/Hybrid-SDN-Book-Chapter-2013.pdf). Critically, RouteFlow expressly describes an "Aggregation" (m:1) mode: bundling a group of switches so that "neighbouring devices or domains can treat the aggregated as if it were a single element." That is the abstraction operation of claim 1, in the same OpenFlow/OSPF context. Date caveat: the CFI '11 paper was published June 2011 and the project's first commit was May 2011 — both before the 2011‑08‑11 priority date — so it appears to qualify as a pre‑AIA §102(a)/(b) printed publication, but the exact publication date should be papered before relying on it.

Combination D: Moy + Ansari '940 + RouteFlow — combines the split-architecture control-plane disaggregation with an explicit OpenFlow-to-FIB translation for OSPF, without requiring the OpenFlow whitepaper.

The problem the invention solves was known and stated

The patent's own Background frames the problem as optimizing inter-area paths without over-sharing intra-area detail and identifies two prior known fixes (external-cost-only; add-internal-cost). The claimed solution is a third, intermediate aggregation. Under KSR, "if a technique has been used to improve one device, and a person of ordinary skill in the art would recognize that it would improve similar devices in the same way, using the technique is obvious" — and where the prior art discloses a range of options, selecting a middle option with predictable trade-offs is an obvious design choice, not invention.

5. The pivotal limitation: "cost of each shortest path between each border switch pair, without… all internal link cost data"

This is the only limitation not squarely met by a single reference, and it is met by the combination:

1. RFC 2328 already pre-computes and advertises aggregated intra-area costs at area boundaries. An ABR computes its shortest path to each destination outside its area and originates a Summary-LSA carrying one aggregated cost, without exporting the area's internal links into the backbone. That is the identical abstraction ("limited intra-area link cost data… without providing all internal link cost data") applied to the controller-as-ABR.
2. The patent's own Background concedes that computing "the internal-link costs and find[ing] the shortest path… between any two of its border switches" was a known alternative implementation.
3. RouteFlow's m:1 aggregation mode and Ansari/ForCES's "network element… hides its internal organization from external entities" (RFC 3746) both teach collapsing an internal set of switches into an externally visible node.
4. Abstracting each border pair as a virtual directed link with the intra-area shortest-path cost is simply the standard link-state representation — i.e., treating the abstracted cost as an edge in the same graph fed to Dijkstra. A POSITA would do this as the natural way to make the controller's global SPF (§16 of RFC 2328) produce optimal multi-area paths.

Motivation, in the art's own words: the aggregation (i) preserves the optimality that external-cost-only routing loses (the patent's own Fig. 6/7 example), (ii) avoids the divergent/contradictory per-neighbor LSA costs of the "add-internal-cost" scheme, and (iii) limits the number of advertised values to O(N²) border pairs rather than O(all internal links), addressing the scalability concern. These are the predictable results of aggregating at the boundary — exactly the trade-offs RFC 2328's ABR design was built to achieve.

6. Dependent claims (2–8; 10–16)

These recite routine implementation details, all met by the primary references, so they rise or fall with the independent claims:

• Claims 2, 10 (send Hello on each external port; receive Hellos) — Moy's Hello protocol.
• Claims 3, 11 (LSA including cost to each external link) — Moy's Router-LSA external-link descriptions.
• Claims 4, 12 (LSA including the shortest-path cost for each border pair) — the aggregation point of §5.
• Claims 5–6, 13–14 (advertise updated link status / Link-State Update) — Moy's flooding on state change.
• Claims 7, 15 (update forwarding tables via OpenFlow) — OF / OpenFlow Spec v1.1 / RouteFlow.
• Claims 8, 16 (initialize OSPF data structures) — Moy's OSPF process initialization.

The apparatus claims (9) require only a conventional server-class node (ingress/egress, network processor, storage) programmed with modules whose functions are performed by Moy (topology, SPF, Hello, LSDB) and OpenFlow (controller module, table installation). Controller hardware of this type is shown, e.g., in Ericsson's own MPLS 2010 controller architecture slide (NOX kernel + OpenFlow protocol) and in the Ansari/SoftRouter CEs.

7. Where the §103 case is weakest (the counter-argument to anticipate)

A skilled drafter defending the patent would press on the "SA area looks like N routers" design — i.e., the controller emitting N Hello packets and N Router-LSAs, one per border switch, to preserve legacy-router interoperability (spec, "Handling of HELLO Messages," FIG. 13–14). That multiplicative behavior is a somewhat counterintuitive choice (it increases message count relative to a single virtual node), and no reference in the record was shown to disclose it verbatim. The rebuttal is that backward compatibility with standard OSPF is a stated design constraint and the "N virtual routers" implementation is the predictable, mechanical way to satisfy it — but this is the point at which a §103 rejection would most likely be contested, and a robust challenge would want a reference (e.g., a router-virtualization or RCP paper) expressly teaching per-interface/per-border-node protocol instantiation.

Additionally, the second cited reference, US 2012/0144066 A1 (Medved et al., June 7, 2012), has a publication date after the 2011‑08‑11 priority date. It can only be prior art if its effective U.S. filing date predates the priority date (pre‑AIA §102(e)). I could not verify its content or filing date within the available lookups, so I do not rely on it here; it should be checked before being used in any ground.

8. Conclusion

Claims 1 and 9, and dependent claims 2–8 and 10–16, would have been obvious under pre‑AIA § 103(a) over Moy (RFC 2328) in view of McKeown et al. (OpenFlow) and Ansari '940 (SoftRouter/ForCES) — and, alternatively, over Moy in view of the Ericsson "Split Router Architecture" presentation (MPLS 2010) or Moy in view of RouteFlow (CFI 2011). Each claim element is either a conventional OSPF operation (Moy), a conventional split-architecture operation (OpenFlow/ForCES/SoftRouter), or a boundary-aggregation step that RFC 2328's Summary-LSA mechanism and the patent's own admitted alternatives already taught. The motivation to combine is supplied by (i) the field's well-known push to separate control from forwarding, (ii) the requirement of interoperability with legacy OSPF routers, and (iii) the known, stated problem of sub-optimal inter-area routing that the prior art's two admitted schemes could not solve without trade-offs. The combination yields nothing more than the predictable aggregation trade-off at an area boundary; no evidence of unexpected results or other secondary considerations appears in the record.

Confidence: Moderate‑to‑high on the mapping of the OSPF/OpenFlow elements (both are cited art of record and I verified them); moderate on the pivotal aggregation limitation because it rests on the RFC 2328 ABR-summary analogy and the patent's own Background admissions rather than on a single reference disclosing the exact claim language; low on the Medved reference, which I could not verify and which is date-problematical. The strongest practical ground remains Moy + OpenFlow + SoftRouter, which is precisely the art the examiner already had before it. Verification recommended: confirm RouteFlow CFI '11 publication date, confirm US 2012/0144066's effective filing date, and re-run a targeted prior-art search for router-virtualization references expressly teaching per-border-switch protocol instantiation.